Inscription / Connexion Nouveau Sujet
Les suites de Papy_Octet.
Bonjour à tous,
Un grand et large Salut à tous ceux qui m'ont aidé dans mes recherche.
Puisque vos précieuses aides commencent à porter leurs fruits, je vais simplement, sans aucune fanfaronnade de ma part, exposer le résultat de mes recherches. Je fais cela par un juste retour des choses en espérant que cela pourra aider l'un ou l'autre dans le futur.
Pour rappel :
Je crée des patrons de tissage de dentelle aux fuseaux (http://le-dentellier.skynetblogs.be/00-nos-dentelles/) avec le logiciel de dessin vectoriel Inkscape puis, avec mon épouse, nous tissons mes créations depuis plus de 25 ans déjà.
J'ai actuellement la possibilité, après avoir dessiné un chemin (un tracé quelconque) d'y ajouter des nœuds supplémentaires soit en précisant le nombre de nœuds que je veux ajouter, soit en spécifiant une distance entre chaque nœuds.
Le principal "défaut" - ou plutôt manquement - à cet outil est que la distance qui sépare deux nœuds consécutifs reste constante tout au long du tracé sélectionné.
En plus, lorsqu'on spécifie la distance entre les nœuds, le dernier segment défini sur le tracé n'aura pas la même mesure que tous les autres puisqu'il récoltera ce qui reste du tracé après le placement de tous les nœuds. Je m'explique : soit un tracé de 100. Je demande de placer des nœuds à 13 les uns des autres. 100 / 13 = 7 nœuds ajoutés et séparés de 13 les uns des autres. Le dernier segment fera : 100 - (7 * 13) = 9 au lieu de 13 comme les autres. Le logiciel travaille avec des pixels et si on introduit une mesure en mm, cm, m, km (ou en mesures anglaises), le logiciel convertit en pixels avant de commencer à calculer. Tout ceci pour dire qu'une erreur de de 4 pixels (de 0.28 mm de long), cela fait peu de différence.
Personnellement, je voudrais, comme j'ai eu la possibilité dans un très ancien logiciel de dessin vectoriel, de répartir les nœuds selon une distance entre chaque nœud consécutif qui varie (positivement ou négativement) selon une progression arithmétique, géométrique, logarithmique et selon une série de valeurs personnelles quelconques.
Et c'est dans cet optique que j'ai sollicité vos aides car depuis plus de 40 ans, je n'ai plus fait de tels calculs, je n'ai plus tâté de l'algèbre, des logarithmes. Mes pauvres neurones se sont un peu rouillés et pour retrouver ces infos dans ma pauvre mémoire, ce fut long et laborieux 
.
Encore mille fois merci pour vos aides si précieuses.
Tout mathématicien sais qu'une suite de nombres est composée d'un nombre entier de termes. C'est une évidence : on ne peut pas écrire un demi nombre (je ne parle pas, ici, de la moitié de la valeur représentée par ce nombre mais d'une partie de son écriture !?).
En fonction des valeurs que je donne au premier et dernier terme de la suite que je veux calculer, et de la somme que j'impose (la somme correspond à la longueur du tracé effectué dans mon dessin qui est mesurée pas mon application et à laquelle je ne peux toucher dans le cadre de l'application. Si je veux modifier la longueur de ce tracé, je dois abandonner mon application et retourner dans le logiciel de dessin.), je dois calculer une série de valeurs, de termes de la suite qui sont les distances entre les nœuds dans le tracé (voir premier post).
Mais avec ces valeurs, il est parfois, souvent, presque toujours impossible d'avoir une suite nette et sans bavure, sans un petit reliquat qui traîne en fin de tracé. C'est quelques dixièmes, centièmes de pixels, mais je suis un peu perfectionniste et je ne veux pas admettre ces "pertes".
Donc, il m'a bien fallu trouver une astuce pour corriger ce problème mineur avec comme objectif principal de CONSERVER UN ASPECT VISUEL CORRECT.
J'avais 3 solutions :
- j'ajoute ce "reste" au dernier terme (segment). Mais s'il est très petit, cet ajout sera, proportionnellement très grand !
- j'ajoute ce "reste" au terme (segment) le plus long de la suite. La différence sera, ici, moins pénalisante que l'option précédente mais si la progression des valeurs est très faible, la modification ajoutée au terme le plus grand risque d'être également pénalisante.
- Après avoir déterminé le nombre de (termes) segments à placer dans la suite, je refais le calcul de certains paramètres de la suite (la raison, la taille du dernier segment) pour approcher au mieux ce qui guide mon travail : la taille des premier et dernier segments (valeur des premier et dernier termes de la suite).
Voici l'algorithme de ce calcul :
Calcul suite arith.
1. Avec 1° terme (= 10), dernier terme (= 3) et Somme (=100).
- Calcul de nombre de termes : nbTermes = (2 * Somme) / ( 1° terme + dernier terme) = 15.3846153846
Je force le résultat à l'untié supérieure => 16 termes.
- Calcul de la raison : (dernier terme - 1° terme)/ (nbTermes - 1) = -0.486631016043 (nb. je me suis serci de la valeur décimale du nombre de termes
pour calculer la raison. Cela me permet d'avoir une meilleure approximation dans le résultat final. Mais lors du calcul des termes,
je force le nombre de termes calculés à l'unité entière immédiatement supérieure (ce qui va provoquer une différence de la somme).
- Calcul des termes de la suite avec ces deux dernières valeurs calculées : 2° terme = premier terme + raison
Contenu (16 termes) dans Suite =
[10.0,
9.5133689839572195,
9.0267379679144391,
8.5401069518716586,
8.0534759358288781,
7.5668449197860976,
7.0802139037433172,
6.5935828877005367,
6.1069518716577562,
5.6203208556149757,
5.1336898395721953,
4.6470588235294148,
4.1604278074866343,
3.6737967914438534,
3.1871657754010725,
2.7005347593582916]
- Somme de la suite = (nbTermes * (1° terme + dernier terme)) / 2 = 101.604278075
Je constate ici que la somme des termes calculés est différente de la somme imposée au départ ! C'est dû au fait que j'ai forcé le nombre de termes à l'unité supérieure dans les calculs.
- Je calcule une nouvelle raison en prenant en compte le nombre de termes (valeur forcée à l'unité immédiatement supérieur : 16), le premier terme imposé : 10 et la somme et je modifie donc légèrement le dernier terme :
Nouveau calcul du dernier segment : dernier terme = ((2 * somme) / nbTermes) - 1° terme = (2*100/16)-10 = 2.5
Nouvelle raison = (dernier terme - 1° terme)/ (nbTermes - 1) = (2.5-10)/(16 1) = -7.5/15 = -0.5
- Je calcule une nouvelle suite de termes
Contenu (16 termes) de la suite =
[10.0,
9.5,
9.0,
8.5,
8.0,
7.5,
7.0,
6.5,
6.0,
5.5,
5.0,
4.5,
4.0,
3.5,
3.0,
2.5]
- Je calcule la nouvelle somme = (nbTermes * (1° terme + dernier terme)) / 2 = (16*(10 + 2.5))/2 = 200/2 = 100 CQFD !
Comme vous le constatez, j'ai conservé la valeur du 1° terme ainsi que la somme et j'ai dû trouver une valeur qui approche la valeur du dernier terme que je spécifiais au départ. C'est une concession à faire pour ne pas avoir de reliquat (en + ou en - dans le tracé final.
Ceci termine le premier algorithme que j'ai développé. D'autres suivront au gré de l'évolution de mes travaux.
A+
Voici la seconde partie de mes calculs.
Ici, l'utilisateur imposera soit le premier soit le dernier terme + le nombre de termes. La somme est toujours la même : la longueur du tracé sélectionné dans le dessin.
Je dois toujours calculer les distances qui sépareront les nœuds ajoutés sur le tracé et tentant de respecter au mieux les valeurs imposées.
Voici l'algorithme de calcul :
2. Avec 1° terme (= 10) ou dernier terme (= 3), nombre de termes (= 13) et Somme (=100).
Dans cet partie, je vais traiter deux options similaires : soit j'impose le premier terme et je dois alors calculer le dernier terme, soit j'impose le dernier terme et alors je dois calculer le premier terme.
Les différences entre les paires de valeurs (premier terme/dernier terme) (10 et 5.384...) et (12.384... et 3) sont dûes au simple fait que les paramètres que j'impose le sont par hasard (on n'est pas à l'école
)... comme ils le seront dans la vraie vie de l'application.
Je connais le premier terme.
- Je calcule le terme manquant : le dernier terme :
dernier terme = ((2 * Somme) / nombre de termes) - premier terme
= (( 2 * 100) / 13) - 10 = 15,384615385 - 10 = 5,384615385
- Je calcule ensuite la raison :
en connaissant le premier terme : raison = (dernier terme - premier terme) / (nombre de segments - 1)
= (5,384615385 - 10) / (13 - 1) = −4,61538462 / 12 = −0,384615385
=> cette suite est décroissante car raison négative.
la suite = [10,
9,615384615,
9,23076923,
8,846153845,
8,46153846,
8,076923075,
7,69230769,
7,307692305,
6,92307692,
6,538461535,
6,15384615,
5,769230765,
5,38461538] => somme = 99,99999997 (13° terme)
Que remarque-t-on ?
Au 13° terme (imposé au début), j'obtiens presque la somme de 100 (à un arondi près à la 8° décimale) et que le dernier terme dépasse de peu les 5.
Je devrai me contenter de cette approximation car tout va dépendre de l'unité de mesure que j'emploierai dans le logiciel de dessin où j'ai à ma disposition le pixel, mais aussi km, m, cm, mm et les mesures anglaise : le yard, le pied, le pouce.
En fin de calcul, je transformerai, si nécessaire, le résultat en pixels puisque le logiciel de dessin travaille toujours, lui, en pixels (1 px = 0.28 mm).
Si en fin de disposition des noeuds sur le tracé il me reste quelques dixièmes ou centièmes de pixels à employer, je les ajouterai au terme le plus grand pour diminuer au possible l'influence visuelle de ce "rattrapage".
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Je connais le dernier terme.
- Je calcule le terme manquant : le premier terme :
premier terme = ((2 * Somme) / nombre de termes) - dernier terme
= (( 2 * 100) / 13) - 3 = 15,384615385 - 3 = 12,384615385
en connaissant le dernier terme : raison = (dernier terme - premier terme) / (nombre de segments - 1)
= (3 - 12,384615385) / (13 - 1) = −9,384615385 / 12 = −0,782051282
mais ... faite bien attention au sens du calcul : on détermine bien les paramètres de la suite en partant du dernier terme !
Donc, la raison qui vient d'être calculée est négative, ce qui est correct si on prenait comme premier terme notre dernier terme. mais alors, la suite va diminuer et deviendra même négative !?
Dans l'énoncé, je voulais que la suite se termine par 3 et je devais calculer la suite des nombres (et le premier terme) en respectant le nombre de termes ET la somme.
=> JE DOIS INVERSER LE SIGNE DE LA RAISON pour inverser la suite du même coup !
la suite : [3,
3,782051282,
4,564102564,
5,346153846,
6,128205128,
6,91025641,
7,692307692,
8,474358974,
9,256410256,
10,038461538,
10,82051282,
11,602564102,
12,384615384] => somme = 100 au 13° terme !
Et ici, au 13° terme de la suite calculée (terme qui sera mon premier terme dans mes calculs), la somme ne vaut que 100. Ce qui est parfait.
Ici également, comme pour le calcul précédent, je travaillerai jusqu'au bout avec des mesures décimales pour les termes puis, lorsque je placerai les nœuds sur le tracé, le reliquat, s'il existe, sera ajouté au terme le plus grand.
Ici se termine le second groupe de calculs avec les progressions arithmétiques.
A+
Bonjour,
Je n`ai pas tout lu.
Tout mathématicien sais qu'une suite de nombres est composée d'un nombre entier de termes.
La suite de tous les entiers impairs et positifs definie par: un=2n+1 avec n appartient à
est-elle composée d`un nombre entier de termes ?
Voici la 3° partie de mes recherches.
Je fournis le premier (= 10) (ou le dernier terme (= 3)), la raison (= 0.825) et, comme toujours, la somme (= 100).
Je dois calculer le nombre de termes puis la suite.
Voici l'algorithme de cette série de calculs :
Ici, je vais devoir calculer le nombre de termes de la suite.
Pour y parvenir, j'utilise une des équations du calcul de la somme = premier terme * (1 - raison^nombre de termes)/(1 - raison)
après triturage de l'équation, j'obtiens :
nombre de termes = (ln(somme - (raison * somme))) / ln(raison)
= ln(100 - (0.825 * 100)) / ln(raison)
= ln(100 - 82.5) / ln(0.825)
= ln(17.5) / ln(0.825)
= 2,862200881 / −0,192371893
= abs(−14,878477497)
J'ai un peu plus de 14 termes donc je force à l'unité entière supérieure => 15 termes.
Si je me contente de ce calcul, la suite devient : [10,
9,175,
8,35,
7,525,
6,7,
5,875,
5,05,
4,225,
3,4,
2,575,
1,75,
0,925,
0,1,
-0,725,
-1,55] => somme = 67,925 au lieu de 100 !
Il semble bien que j'ai un problème car les valeurs deviennent négatives et cela n'est pas possible dans mon application.
"L'erreur" provient du fait que, sur bas des données fournies, j'ai calculé un nombre de termes théorique pour la suite. Mais le calcul a été fait avec la raison fournie. Or moi, je veux pouvoir utiliser les paramètres de départ comme base de calcul pour pouvoir calculer les distances entre les nœuds que je vais ajouter sur le tracé sélectionné dans mon logiciel de dessin.
Je calcule la valeur du dernier terme en fonction du nombre de termes déterminé = ((2 * somme) / nombre de termes) - premier terme
= ((2 * 100) / 15) - 10
= 13,333333333 - 10
= 3,333333333
Je dois donc, maintenant, re-calculer une nouvelle raison = (dernier terme - premier terme) / ((nombre de termes - 1)
= (3,333333333 - 10) / 14
= −0,476190476
Avec cette nouvelle raison (qui n'est pas si éloignée que cela de la raison donnée au départ), je calcule la nouvelle suite de termes :
[10,
9,523809524,
9,047619048,
8,571428572,
8,095238096,
7,61904762,
7,142857144,
6,666666668,
6,190476192,
5,714285716,
5,23809524,
4,761904764,
4,285714288,
3,809523812,
3,333333336] => somme = 100 !
Bien entendu, dans l'algorithme final, je devrai encore voir comment traiter les décimales dans les valeurs des termes puisque dans le logiciel de dessin, il travaille uniquement en pixels qui, eux, ne sont pas divisibles.
Il me reste une série de calculs à envisager pour terminer ce groupe.
A+
Voici la 4° et dernière partie des calculs en rapport avec la suite arithmétique.
Je fournis, dans le logiciel de dessin, le nombre de termes, la raison et la somme. Il me faut ensuite calculer les différents termes de la suite.
Voici l'algorithme de calcul :
Je vais donc devoir calculer les premier et dernier termes pour pouvoir créer ma liste de valeurs avec lesquelles je pourrais disposer les nouveau nœuds sur le tracé sélectionné dans mon logiciel de dessin vectoriel favori.
Je conserve toujours les données de départ : nombre de termes = 13, la raison est fixée à 0.825 et la somme est toujours de 100.
Pour résoudre ce problème, je dois utiliser un système de 2 équations à 2 inconnues. Et là, il y a eu du travail pour retrouver ces infos dans les méandres de mes vieux neurones
! Mais grâce à de nombreuses informations trouvées sur le web, j'y sis enfin parvenu.
La première équation est : somme = (nombre de termes * (premier terme + dernier terme)) / 2
Je mets l'équation en forme : premier terme + dernier terme = (2 * somme) / nombre de termes
La seconde équation est celle du calcul de la raison = (dernier terme - premier terme) / (nombre de termes - 1)
Je mets mon équation en forme : dernier terme - premier terme = raison * (nombre de termes - 1)
mon système de 2 équations à deux inconnues (premier et dernier terme) est :
a. premier terme + dernier terme = (2 * somme) / nombre de termes
b. dernier terme - premier terme = raison * (nombre de termes - 1)
je fais la somme des deux équations et j'obtiens :
2 * premier terme = ((2 * somme) / nombre de termes) + raison * (nombre de termes - 1)
premier terme = ((2 * somme) / nombre de termes) + raison * (nombre de termes - 1) / 2
Je calcule la valeur du premier terme
= (((2 * somme) / nombre de segments) + (raison * (nombre de termes - 1))) / 2
= (((2 * 100) / 13 ) + ( 0.825 * (13 - 1 ))) / 2
= (15,384615385 + 9.9 ) / 2
= 25,284615385 / 2
= 12,642307693
Il me reste à remplacer premier terme dans l'équation a ci-dessus par sa valeur :
premier terme + dernier terme = (2 * somme) / nombre de termes
12,642307693 + dernier terme = (2 * 100) / 13
dernier terme = ((2 * 100) / 13) - 12,642307693
= 2,742307692
Je peux calculer la suite : [12,642307693,
11,817307693,
10,992307693,
10,167307693,
9,342307693,
8,517307693,
7,692307693,
6,867307693,
6,042307693,
5,217307693,
4,392307693,
3,567307693,
2,742307693] => somme = 100 au 13° terme !
La procédure sera la même dans le cas où je calculerai le dernier terme pour commencer puis le premier.
Cette 4° partie termine la série de calculs qui me sont nécessaires pour créer la partie de l'application qui concerne la variation des distances entre les nœuds selon une progression arithmétique.
Ouf !
Je vais maintenant me consacrer un peu à l'encodage de ces algorithmes avant de passer aux calculs pour une suite géométrique.
Et le prochain groupe de calculs : ce sera pour une suite logarithmique !
J'ai encore bien du travail sur la planche
Et dire qu'il y en a qui osent dire qu'ils s'ennuient
Bonne lecture.
A+
Annuler
connectez vous