Bonjour à tous ! Excusez-moi pour ce titre, mais ma curiosité m’a poussé à le faire. Pendant que je m’ennuyais, j’ai "trouvé" quelque chose (c’est relatif, je ne l’ai juste pas encore vu ailleurs). Donc au début, on prend un nombre aléatoire. Le procédé :
On lui additionne le nombre qui a les mêmes chiffres, mais dans l’autre sens (Donc 635 -> 536), et ce dernier est multiplié par -1 (donc pour le nombre 635 on fait : 635 (+) - 536, et pour un nombre négatif : -635 + 536).
Puis, avec le résultat, l’on continue le processus jusqu’à tomber sur 0.
Sauf que voilà, pour certains nombre, ce processus est infini. Donc j’ai décidé de faire une "simulation" informatique pour les 10.000 premiers nombres. Et l’on s’aperçoit que avant 1000, tous les nombres ne sont que des Finombres (j’ai appelé comme ça les nombres où le processus ce termine.) et qu’à partir de 1000 (enfin 1012), tous les multiples de 11 sont des Infinombres (nombres où le processus ne ce termine jamais). Sauf que tout les 5 multiples de 11 (91x11, 96x11, 101x11, 106, 111, 116....) c’est des Finombres. (Il y a quelque exceptions et même, après c’est 520x11, 525x11, 530x11... mais l’écart est le même.)
Donc, j’aimerai savoir si quelqu’un sait pourquoi il y a ce résultat qui n’est (logiquement) pas aléatoire.
Merci !
EDIT : Après vérification, ce n’est pas tout le temps les multiples de 11. Et les premiers nombres à partir de 10000 ont le même écart, mais sont par deux (par exemple 10011 et 10012 sont des Infinombres, puis 10016 et 10017... (Ce sont des exemples, je n’ai plus mon test sous les yeux :/))
Sur ce thème, si tu regardes des articles sur 'Preuve par 9', tu devrais avoir des choses plus ou moins en rapport.
Et il a un truc connu aussi sur ce même thème , tu prends un nombre à 4 chiffres, par exemple 1263. Tu mets les chiffres dans l'ordre, du plus petit au plus grand, (1236) et dans l'ordre inverse (6321).
Tu fais la soustraction. Et tu répètes l'opération.
A partir de n'importe quel nombre, tu tombes à un moment sur 1467.
Pour ton cas, ce que tu peux remarquer, c'est que abcd-dcba=999(a-d)+90(b-c) ; Donc en fait, ce qui compte c'est (a-d) et (b-c)
Comment décides-tu que le processus est "infini". Est-ce que tu retombes sur le même nombre? Et tout de suite ou après un certain nombre d'ittérations?
Te rappelles-tu comment tu fais ta simulation? Est-ce que tu décomposes tes nombres et les recompose à l'envers, ou si tu fais de l'arithmétique simulée avec un tableau de "digits" décimaux?
Je serais intéressé à faire une simulation plus loin que 10000 et je pense avoir trouveé la façon la plus rapide de le faire.
Je suppose que tu ne considères pas les zéro avant les chiffres: 01 > 10 ...
Le Tout est souvent plus grand que la somme de ses parties.
Merci !! Pour que le processus soit infini, je fais répéter le processus 1000 fois. Si ça dépasse les 1000 opérations, le nombre est compté comme "infini". C’est pas parfait, certes, mais c’est suffisant pour les premiers. Et oui, les 0 ne sont pas pris en compte. Je peux vous donner le programme si vous voulez.
Si à un moment, tu repasses par un nombre déjà vu, tu peux t'arrêter là. Tu es sûr que ça boucle, et tu connais même précisément la liste des nombres qui tournent en rond ensemble. Et à mon avis, avec ce critère d'arrêt, tu t'arrêteras systématiquement avant 50 boucles. Sauf bien sûr tu t'amuses à traiter des nombres très très grands, des nombres à 40 ou 50 chiffres ; dans ce cas, ça peut être plus long avant de repasser 2 fois par le même nombre.
J’ai trouvé quelque chose !!!
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.