@lourran Oui comme tu le décris effectivement, le cartographe de cette époque n'imagine pas autre chose que ce qu'il connait. Il ne pourra jamais prévoir les découvertes non plus. Remarque que ce n'est pas son taf. Je comprends bien que l'inconnu non cartographié, c'est dans le sens de ta métaphore les cycles triviaux, etc. Il n'y a rien dans l'arbre existant qui puisse en donner un signe annonciateur (ça n'empêche pas de chercher un peu, mais bon) Ton argument est costaud, et je le reconnais dur à contrer. On pourrait quand même dire deux choses : 1) A ce moment de l'histoire, avant l'arrivée d'un Christophe Colomb de l'arithmétique qui va tout chambouler, l'arbre-carte n'est pas par terre. Des machines continuent à explorer les bords de ce monde, rien de bouge. Hypothèse de la stabilité : ça peut continuer comme ça. Beaucoup le pensent. 2) Mais on doit admettre qu'il peut y avoir une découverte bouleversante. Cela peut venir du calcul ou d'une démonstration. Personne ne sait. Je ne prétends pas trancher un dilemme pareil. Comme je suis plutôt un "stabiliste" je cherche plutôt à montrer le caractère stable de l'arbre. On peut montrer que la structure de l'arbre élaborée sur des règles de construction indépendantes de l'algorithme peut produire toutes les positions nécessaires et venir infiniment "matcher" la position potentielle d'un entier dont théoriquement personne n'a jamais vérifié le chemin. Imagine que mon programme puisse écrire un code de lignée qui remplirait des pages et des pages. Le programme dirait qu'il n'a aucune idée de l'entier qu'il représente mais que la position est fiable. On peut ainsi prouver que même pour des entiers très très grands, il y a toujours une position dans l'arbre. Cette position est bien plus facile à décrire et on peut prouver qu'elle est viable si on a démontré que les règles sont logiques.
Si 16 est toujours au début de la ligne, 349525 est le premier impair trouvé après 17 étapes paires : arrondi.sup(17/2) = 9 349525 est le neuvième départ de branche depuis les puissances de 2 : il provient de 2^20
L'arbre a un nombre fini d'orbites au moment où quelqu'un y cherche quelque chose. Mais évidemment l'arbre a un nombre infini d'orbites, et tant qu'on ne cherche pas à le représenter, il est infini.
Pfffff là encore, quelle découverte : quand on étudie des suites, on ne peut écrire que quelques termes mais il y a « en fait » une infinité de termes.
Imagine que mon programme puisse écrire un code de lignée qui remplirait des pages et des pages. Le programme dirait qu'il n'a aucune idée de l'entier qu'il représente mais que la position est fiable. On peut ainsi prouver que même pour des entiers très très grands, il y a toujours une position dans l'arbre.
Je rectifie un peu ta phrase : Je remplace juste le mot 'des' par le mot 'certains' , ça ne change quasiment rien, mais je préfère. Obsession de matheux. Parfois le mot des est mal interprété, alors que le mot certains laisse beaucoup moins de doutes.
Imagine que mon programme puisse écrire un code de lignée qui remplirait des pages et des pages. Le programme dirait qu'il n'a aucune idée de l'entier qu'il représente mais que la position est fiable. On peut ainsi prouver que même pour certains entiers très très grands, il y a toujours une position dans l'arbre.
Maintenant, reprenons cette dernière phrase : On peut ainsi prouver que même pour certains entiers très très grands, il y a toujours une position dans l'arbre.
Soit, et alors ? Tu veux prouver à ton tour un truc qui est connu, admis, prouvé depuis plus de 60 ans ? Un truc qu'on peut prouver en 3 minutes quand on entend parler de cette conjecture pour la 1ère fois. C'est ça ton challenge ?
Tu me dis, j'oublie. Tu m'enseignes, je me souviens. Tu m'impliques, j'apprends. Benjamin Franklin
@lourrran "C'est ça ton challenge ?" Mon challenge est de construire un arbre sans l'algorithme de Collatz en se basant sur des règles qui génèrent une arborescence identique. Voilà par exemple un code de lignée un peu particulier 1.2.1.1.1.2.1.1.1.2.1.1.2.1.1.2.1.1.1.2.2.1.1.2.2.1.1.1.1.2.2.2.2.1.2.2.2 Ce code est intéressant parce qu'on ne peut pas écrire un code aussi long avec aussi peu de 2. Par l'effet complexe des cycles de multiples de 3 qui donnent des impairs sans descendance, il n'est pas possible d'écrire un code comme 1.1.1.1.1.1.1.1.1.1.1.... parce que ça n'existe pas dans l'arbre. Il faut composer avec des deuxièmes descendants toutes les fois où le premier est stérile. pour info, ce code de lignée est l'itinéraire vers 105 892 338 373
Tu ne veux pas assumer ce que tu as écrit, et donc, on va devoir te le rappeler régulièrement.
On peut ainsi prouver que même pour certains entiers très très grands, il y a toujours une position dans l'arbre. Mon challenge est de construire un arbre sans l'algorithme de Collatz en se basant sur des règles qui génèrent une arborescence identique. Et cet arbre permettra de prouver un résultat qu'on peut prouver par ailleurs en 3 minutes.
Tu me dis, j'oublie. Tu m'enseignes, je me souviens. Tu m'impliques, j'apprends. Benjamin Franklin
Si je comprends bien ta méthode, supposons que tu veuilles coder l'entier impair $n$ :
Tu calcules la suite standard (avec les termes pairs) de $n$, puis tu l'inverses.
Tu cherches un 16 et à partir de lui tu comptes le nombre d'étapes paires jusqu'au premier terme impair. As-tu prévu le cas où le 16 ne serait pas égal à $3 \times 5+1$ mais à $(3 \times 85+1)/2^4$, ce qui n'est pas du tout la même chose ?
Tu divises ce nombre d'étapes par 2 et tu arrondis à l'entier supérieur. Pourquoi ? Qu'est-ce qui justifie cette opération ?
Tu cherches le nombre d'étapes jusqu'aux termes impairs suivants, et tu appliques à chacun la même opération.
Je reprends ton exemple de $n=368223$ (les impairs sont en gras) :
puis 4 fois $\lceil 1/2 \rceil=1$ pour arriver à 368223.
Résultat : 368223 est codé 9.2.1.1.1.1.
Maintenant, disons qu'on veuille retrouver 368223 à partir de ce code. Comment fait-on ? C'est d'autant plus compliqué que le code 1, par exemple, peut être interprété de 2 manières : $\lceil 1/2 \rceil$ ou $\lceil 2/2 \rceil$. De la même manière, le code 9 peut correspondre à $\lceil 18/2 \rceil$ ou $\lceil 17/2 \rceil$. Dans ces conditions, tu ne peux pas savoir quel est le bon exposant de 2 à appliquer à chaque étape de la remontée vers $n$, puisqu'à chaque fois tu as deux possibilités.
@Wilfrid Il est bien sûr possible de retrouver l'entier depuis son code de lignée Je publierai la méthode cet apm Sinon pour 16 : la toute première bifurcation de l'arbre est 16--->32 ou 5 De ce fait quelque soit l'orbite où se trouve un entier , son chemin reviendra à 16 soit par la porte 32, soit par 5 Donc dans ma série, 16 remplace le 1 comme point d'arrivée
@PMF : Sinon pour 16 : la toute première bifurcation de l'arbre est 16--->32 ou 5
Je ne comprends pas ce que tu écris. Si on s'en tient aux prédécesseurs de 1 non multiples de 3, qui donc possèdent des prédécesseurs, c'est-à-dire 5, 85, 341, 5461, 21845, ..., on trouvera 16 en effectuant les opérations suivantes :
$3 \times 5+1$
$(3 \times 85+1)/2^4$
$(3 \times 341+1)/2^6$
$...$
Dans le premier cas il existe effectivement une bifurcation, en l'occurrence 5 puisqu'il possède une infinité de prédécesseurs impairs vers lesquels on peut bifurquer. Mais lorsque la suite ne passe pas par 5, le 16 en question ne correspond pas à une bifurcation. Exemple : ..., 85, 256, 128, 64, 32, 16, 8, 4, 2, 1. Tu t'es focalisé sur 5 en tant qu'avant-dernier terme de la suite, mais ce n'est qu'un cas parmi d'autres, bien qu'il soit le plus répandu. Prenons deux suites :
A : 111, ..., 53, 5, 1 B : 113, 85, 1
Dans le cas de A, le premier chiffre du code sera le nombre d'étapes paires séparant 53 de 5 (avant division par 2). Dans le cas de B, ce sera le nombre d'étapes paires séparant 85 de 16, ce qui fait que 85 n'est plus considéré comme un des prédécesseurs directs de 1 mais comme le premier terme impair rencontré lors de la remontée, alors que logiquement ce devrait être 113. Tu trouves ça cohérent ? Eh bien ça ne l'est pas !
Voyons maintenant comment tu fais pour retrouver le premier terme d'une suite à partir de son code. Je suis impatient !
On lui avait déjà fait cette remarque l'année dernière, mais il ne prend en compte aucune remarque. Pour faire des 'économies', il arrête le chemin à 16. Avant, il l'arrêtait au dernier impair. Le nombre 1 ne peut pas s'écrire dans ce modèle, il n'existe pas.
Je sais, je chipote. Ce problème n'est pas catastrophique. On a une voiture qui n'a pas de roues et pas de moteur, on a oublié l'essieu avant, le châssis est vraiment de mauvaise qualité, et je suis en train de critiquer parce que le gris du tableau de bord est un peu trop clair.
Tu me dis, j'oublie. Tu m'enseignes, je me souviens. Tu m'impliques, j'apprends. Benjamin Franklin
Un coup d'oeil sur ce tableau svp. C'est le début de l'arbre tel que l'écrit mon script vba (déjà publié 2 fois) Que voyez-vous ? Que l'arborescence débute après la ligne "16" avec la ligne "32, 5" : c'est la première fois où on a 2 résultats possibles 16*2 ou 16-1/3 Comme tout chemin partant de 1 passera par 32 ou 5, 16 est le point de repère du code de lignée
Il serait aussi juste de dire que tout entier transformera un impair i via x itérations i*2n+1/3 jusqu'à ce que 3i+1 = 2^n : la solution du chemin est trouvée à ce moment. Selon le n obtenu, on aura le premier numéro de lignée en calculant 0,5*n-1 Mais ce n'est pas assez frappant de dire que l'algorithme finit toujours par ramener un entier à une puissance de 2 plutôt qu'à 1
La souche de l'arborescence, le point d'ancrage de la hiérarchie c'est 2^4
Tu ne t'en souviens peut-être pas, mais ce script VBA, c'est moi qui te l'ai donné ... un truc bricolé un soir en 20 minutes, pas beaucoup d'intérêt.
Remplir un arbre, pour le plaisir de remplir un arbre, pourquoi pas. On remplit un arbre, au même titre qu'un gamin ferait du coloriage. C'est cool, ça passe le temps, et ça n'a aucun objectif 'scientifique'. Remplir un arbre pour démontrer que l'arbre de Collatz peut contenir des entiers très grands (c'est l'objectif que tu as annoncé), c'est clownesque.
Tu me dis, j'oublie. Tu m'enseignes, je me souviens. Tu m'impliques, j'apprends. Benjamin Franklin
la façon dont je procède pour retourner un entier depuis un code de lignée est la suivante
Voici le code de lignée que nous allons décoder : 4.3.2.2.2.1.1
On traduit toujours de gauche à droite donc ici on part de x = 4 pour trouver l'ancêtre n = 2x+2 = 10 l'ancêtre est 2^n-1/3 = 341
Maintenant on peut continuer en utilisant le rang r du descendant i' de 341 (qu'on appellera i)
Dans excel la formule de i' c'est ça : =SI(MOD(i*2^(2*r)-1;3)=0;(i*2^(2*r)-1)/3;(i*2^(2*r-1)-1)/3) Que l'on peut expliquer comme : si le modulo 3 de (i*2^(2*r)-1 est 0, alors calcule (i*2^(2*r)-1)/3; sinon calcule (i*2^(2*r-1)-1)/3)
On fait donc l'opération avec i = 341 et la valeur suivante du code de lignée qui est 3 : i' = 3637
On refait la même opération avec i = 3637 et la valeur suivante du code de lignée qui est 2 : i' = 19397
On refait la même opération avec i = 19397 et la valeur suivante du code de lignée qui est 2 : i' = 51725
On refait la même opération avec i = 51725 et la valeur suivante du code de lignée qui est 2 : i' = 137933
On refait la même opération avec i = 137933 et la valeur suivante du code de lignée qui est 1 : i' = 91955
On refait la même opération avec i = 91955 et la valeur suivante du code de lignée qui est 1 : i' = 61303
@lourrran Sans vouloir entamer un procès en propriété intellectuelle, j'ai fait de A à Z ce script VBA qui construit l'arbre. Nos avons échangé des scripts pendant le fil "Un modèle pour Syracuse" mais celui-ci n'en fait pas partie, même si tu pourras toujours y retrouver des similitudes. Dans un script concernant Collatz, on va toujours trouver des 3n+1/2^n entre autres. Et puis forcément on va aller dans un sens ou dans un autre selon que l'on utilise l'algorithme ou son inverse.
Si je peins un tableau avec des ronds rouges, tous les tableaux avec des ronds rouges ne sont pas les miens.
Tu peux critiquer mon travail s'il ne te plait pas mais pas de dire que quelque chose t'appartient si ce n'est pas vrai.
Le post est un peu long à lire parce qu'il y a beaucoup à développer sur ce point important. Je commence donc par un résumé.
On va comparer un arbre de Collatz avec un arbre généré par l'algorithme simplifié (qui ne contient pas la multiplication par 3). On va ensuite montrer que ces deux arbres ont fondamentalement la même structure. Comme on montre que l'arbre de l'algorithme simplifié contient tous les entiers naturels, la question se pose de savoir pourquoi un autre arbre de même structure ne pourrait pas en faire autant. Où est donc exactement leur différence ?
1) l'arbre généré par l'algorithme simplifié (ou arbre simplifié)
On construit cet arbre presque de la même manière que celui de Collatz: on double toutes les valeurs de la ligne précédente et on ajoute à la fin de cette nouvelle ligne i+2, i étant l'impair situé en fin de la ligne précédente. Dans l'arbre, chaque colonne ne contient qu'un impair (une nouvelle colonne = un nouvel impair). Tous les impairs sont situés sur la diagonale qui borde le coté droit. Les puissances de 2 sont en première colonne. Toutes les autres valeurs du tableau sont des pairs de la forme i*2^n. Ces points sont identiques à l'arbre de Collatz.
2) L'arbre simplifié contient tous les entiers On va prendre la suite arithmétique de 1 à 32 contenue dans cet arbre. Chaque nouvelle colonne débutant par i+2, il faut 32/2 = 16 colonnes et 16 lignes pour arriver à l'impair 31 en bas à droite. Nous avons donc toute la suite impaire de 1 à 31 Comme la colonne 1 contient les puissances de 2 jusqu'à 2^15 (exposant = n° de ligne -1),nous avons donc 2,4,6,8,16,32 Il ne manque donc que les pairs de forme i*2^n <32 que nous trouvons évidemment associés aux colonnes contenant les impairs i de 3 à 15 (en bleu) Le plus grand i*2^n est 30. Il est issu de 15 qui se trouve en colonne et ligne 8. Il reste donc pour 15 la possibilité d'atteindre 15*2^9 en dernière ligne, valeur largement au-dessus de 30. Tous les autres i*2^n devant atteindre une valeur plus basse que 30 et étant situés plus haut dans la tableau, la série 6, 12, 24, 10, 20, 14, 28, 18, 22, 26, est complétée. Un arbre de n colonne contient donc une valeur impair maximale impaire i = 2n-1, et toute la suite de 1 à i+1 est incluse dans cet arbre. Cet arbre contient donc tous les entiers. On arrive ici à une deuxième équivalence avec l'arbre de Collatz : les entiers pairs y sont surreprésentés. De même pour compléter la suite 1 à 32, il faut générer 136 éléments dont la valeur maximale est 49152. Un arbre de Collatz présente ce même défaut de "surconsommation" puisque l'on a vu que la série de 1 à 27 implique un arbre de Collatz qui contiendrait des milliards d'éléments. Mais c'est la même propriété : une petite série demande un grand tableau.
3)Où est la différence? Il y a une seule différence entre ces arbres : les impairs dans l'arbre de Collatz n'arrivent pas dans l'ordre des colonnes. Voyons ce que peux donner un arbre de Collatz en réordonnant les impairs : Nous avons là "à la mode Collatz" la série des impairs de 1 à 26 (cad avant le fameux 27 qui demanderait de calculer des millions de colonnes). La suite des entiers de 1 à 26 est contenue dans ce tableau exactement comme dans le cas de l'arbre simplifié Alors bien rangé notre arbre de Collatz est-il le même qu'un arbre simplifié ? La différence est bien sûr que nous perdons l'alignement décroissant des colonnes (en diagonale pour l'arbre simplifié, en courbe pour Collatz). Rappelons aussi que pour avoir ce tableau il faut calculer 24 lignes et 143 colonnes. Voici les positions pour i de 3 à 25 dans l'arbre :
Cela parait si simple d'associer un i avec ses coordonnées (ligne, colonne). Construire un arbre, c'est à la fois générer toutes les descendances que l'on traduira avec les codes de lignées et de ce fait obtenir une position (ligne, colonne) pour chaque impair du tableau. Il ne serait pas impossible de construire directement un tel tableau dans l'ordre des impairs. Tout le problème, on l'aura compris, c'est de positionner chaque impair sur la bonne ligne. Or ce résultat dépend de la construction intégrale de l'arbre ou de générer pour chaque impair les itérations i*2n+1/3 jusqu'à ce que 3i+1 = 2^n. On repère alors ce 2^n dans la colonne 1 et on place le i une ligne plus bas. La colonne se remplit ensuite avec les i*2^n. C'est donc certainement faisable en code mais la question est : pourquoi cette possibilité technique très simple (placer un i sur sa ligne et passer à i+2) ne peut-elle se répéter jusqu'à l'infini ? Dans l'infini des combinaisons (l,c) de i, il en existerait un qui serait sans coordonnées.
4) conclusion pratique Si on ne peut trancher en théorie sur le i introuvable dans l'arbre, il est possible de faire un code efficace qui produirait des données dans le format suivant :
Ya plein de jolies couleurs et de jolis tableaux, mais PMF, il faut commencer à se rendre à l'évidence que tout cela ne sert à rien ! Vous n'avez malheureusement pas pris le temps de lire attentivement les quelques messages vous démontrant les contre-sens que vous faites dans le modèle de pensée que vous vous êtes construit concernant cette conjecture. Votre "perception", ou "conception" de la conjecture est erronée, et tant que vous ne changerez pas cela, vous ne pourrez avancer.
Remets-en une couche de mauvaise foi si tu veux, mais puisque tu aimes tant me citer tu aurais pu noter que mon mail commence par : "Sans vouloir entamer un procès en propriété intellectuelle, "
Si je mets un code VBA sur un fil, c'est que je me moque de la propriété intellectuelle puisque je le donne ! Mais je peux encore dire que je l'ai fait.
Ton attitude sur ce fil n'est pas très cool. L'ironie c'est bien, et tu es libre de ne pas apprécier ce que je dis, même si c'est un peu systématique. Et puis à un moment ton ironie devient mensonge et tu déformes mes propos. Pour moi ça tourne au forum à deux boules comme il y en a partout sur le net.
Je te cite : « même si tu pourras toujours y retrouver des similitudes » C’est triste, c’est toi qui dit à lourrran cette phrase.
Je n’y peux rien. La prétérition c’est justement cela. Regarde dans le dictionnaire.
Là où tu as raison c’est qu’il s’agit d’un sarcasme de ma part. J’avais le temps, que veux-tu.
Pour rappel tu n’as jamais daigné répondre à mes questions simples par des messages courts. Tu réponds toujours par des graphiques et des romans.
Je m’attribue donc ce droit sarcastique face à ton irrespect total envers quelqu’un qui te lit et souhaite te comprendre.
Cela fait deux fois (?) que tu parles de mauvaise foi me concernant. C’est l’hôpital qui se fout de la charité. À bon entendeur (même s’il se bouche les oreilles) !
Je ne comprends pas ton attitude. Tu as commencé par des questions du type "la question que je te pose, et à la réponse que tu feras je te dirais que tu ne m'auras pas répondu"...Donc ta question comporte sa propre stratégie rhétorique : on a fait mieux et plus subtil pour convaincre.
Je t'ai toujours répondu mais dans le style qui est le mien. Publier des graphiques est aussi une preuve de travail. C'est une façon de penser. Pour les romans, excuse-moi mais j'ai un peu de mal avec la stylistique SMS.
Oui je ne m'exprime pas de la façon habituelle pour parler de mathématique. Cela ne veut pas dire que ce soit incompréhensible.
Donne-moi une fois stp un retour précis et pas des généralités : peux-tu me dire par exemple ce que tu penses de la comparaison que j'ai faite ce matin entre un arbre simplifié et un arbre de Collatz ? Penses-tu que l'absence d'ordre (ou du moins l'ordre très particulier) de l'apparition des impairs dans l'arbre serait la condition qu'un entier un jour ne puisse y entrer? Ou alors comme je le crois, quelque quoi que soit cet ordonnancement, au final tout impair trouvera sa place dans l'arbre. Et ne me dis pas que tu ne comprends pas ce texte en 4 points, précédés d'un résumé, et illustré des graphiques qui sont indispensables.
Qu'il y ait du travail, personne ne le nie. Les questions intéressantes, c'est : où comptes- tu aller, comment comptes-tu arriver à tel ou tel objectif. Soit tu ne réponds pas à ces questions, soit tu y réponds, et alors, il devient évident que tu n'as rien compris au problème et aux difficultés dans la notion "d'infini dénombrable"
Imagine un type qui dit qu'il veut construire un pont de Brest à New-York. Et pour ça, il achète un terrain près de Brest, et il construit une tour très haute, et quand on l'interroge, il dit qu'en construisant une tour très très haute, il arrivera à New-York.
Et le type dit : vous voyez bien que je travaille beaucoup.
Tu me dis, j'oublie. Tu m'enseignes, je me souviens. Tu m'impliques, j'apprends. Benjamin Franklin
Trouves-tu qu’il s’agisse d’un message ironique, violent, de mauvaise foi, manquant de respect, peu cordial ? Lis ensuite ta réponse qui au mieux tourne autour d’un pot que je ne visualise pas ou qui de mon point de vue montre un manque de respect évident : tel un politique qui dis « je réponds » mais qui ne répond pas. Du mépris dit-on parfois.
Dernière solution : tu ne comprends pas mon message et tu crois y répondre quand même.
« Je t’ai répondu mais dans un style qui est le mien » qui consiste à ne pas répondre en produisant du Big Data !
Quelques phrases en bon français permettraient à tes malheureux lecteurs de dégager une philosophie, une idée directrice. Même les grands s’y prêtent. On est samedi, il y a un beau ciel bleu: tu penses bien que personne ne va se plonger dans un fouillis de colonnes chiffrées sans même être sûr que ça mène quelque part. D’autant que tout le monde est persuadé que ça ne mène nulle part (ni à Brest, ni à New York).
A la suite de mon topo sur la comparaison entre un arbre simplifié et un arbre de Collatz, on pourrait en déduire 3 phases :
1) simplicité : utiliser l'algorithme dont on a supprimé la multiplication par 3 pour générer un arbre simplifié. Cet arbre englobe tous les entiers. 2) complexité : utiliser l'algorithme classique de Collatz. Même s'il ressemble sur de nombreux points à un arbre simplifié, la complexité de la répartition des impairs ne peut garantir que tous peuvent intégrer l'arbre. 3) impossibilité : en modifiant l'algorithme avec d'autres facteurs que 3, l'expérience montre vite que les suites divergent.
Donc le choix de facteurs (*1, *3, *i>3), pourtant très simples paramètres de cet algorithme, nous fait passer de la simplicité, à la complexité puis à l'impossibilité. Ce réglage ne tient donc qu'à un fil.
@Wilfrid 2.2.1.1.2.1.2.2.1.1 ? Je pars du principe que tu as bien compris que le premier chiffre à gauche (2 ici) est la relation au premier impair issu d'un 2^n soit 1 pour 5, 2 pour 21, 3 pour 85, 4 pour 341, etc... Aie!!! 2 renvoie à 21 qui est un multiple de 3. Il ne peut avoir de descendance donc tout le reste du code est impossible Etait-ce une question piège ?
@df Sans prétention aucune, mon français me semble très correct. Est-ce que tu comprends la comparaison que j'ai faite entre un arbre simplifié et un arbre de Collatz en transformant le *3 de l'algorithme en *1. Qu'est-ce que vous avez tous avec les tableaux et les données ? Ce n'est pas assez théorique ? C'est pourtant la réalité.
Désolé mais je réponds par des questions. Que penses-tu de la comparaison entre arbre simplifié et arbre de Collatz? Pourquoi sont-ils si semblables et quel est pour toi le vrai marqueur de complexité dans celui de Collatz? Pourquoi tous les impairs ne finiraient-ils par trouver une valeur de colonne et de ligne, une position toute simple dans un arbre aussi grand soit-il?
Puisque PMF persiste à nous combler de tableaux je ne peux résister à lui présenter les trois tables suivantes représentant le début de la table de Collatz pour le cas d'origine 3x+1, pour le cas 3x-1 et pour le cas 3x+5. Je lui laisse découvrir ces tables
@lourrran @Wilfrid Je veux bien être à des lustres de la grande compréhension mathématique qui est la votre, mais ce que je fais dans Excel est correct.
Allez comme vous êtes les deux seuls à l'utiliser, on passe aux exercices pratiques : Exo : Retourner un entier depuis un code de lignée Dans un tableau de A1 entre n°, puis de A2 à A12 entrer la suite 1 à 11 en B1 taper 5 pour faire simple en B2 entrer : =SI(MOD($B$1*2^(2*A2)-1;3)=0;($B$1*2^(2*A2)-1)/3;($B$1*2^(2*A2-1)-1)/3) attention il faut bien mettre des caractères "$" avant b et 1: taper bien "dollar" B "dollar" 1 (l'affichage le vire) copier B2 de B3 à B12 en face de 1,2,3,4... s'affichent 3, 13, 53, 213... Vous avez tous les descendants du 5 par ordre d'apparition.
Astuce maintenant : taper 1 en B1 en face de 1,2,3,4... s'affiche 5, 21, 85, 341... Sympa non, tous les premiers impairs directement ici de 2^n
Bon essayons maintenant de traduire 1.2.1.3.1.5
Step by step : "1." : je tape 1 en B1 : la concordance de 1 est 5 "2." : j'entre 5 en B1 : la concordance de 2 est 13 "1." : j'entre 13 en B1 : la concordance de 1 est 17 "3." : j'entre 17 en B1 : la concordance de 3 est 181 "1." : j'entre 181 en B1 : la concordance de 1 est 241 "5." : j'entre 241 en B1 : la concordance de 5 est 82261
@Zgrb Désolé mais je réponds par des questions. Que penses-tu de la comparaison entre arbre simplifié et arbre de Collatz? Pourquoi sont-ils si semblables et quel est pour toi le vrai marqueur de complexité dans celui de Collatz? Pourquoi tous les impairs ne finiraient-ils par trouver une valeur de colonne et de ligne, une position toute simple dans un arbre aussi grand soit-il?
Ce sont les mêmes arbres ! Présentés différemment ! C'est pour cela qu'ils se ressemblent ! Voilà donc pourquoi ton arbre ne présente aucun intérêt supplémentaire.
Pour ta dernière question : "Pourquoi tous les impairs ne finiraient-ils par trouver une valeur de colonne et de ligne, une position toute simple dans un arbre aussi grand soit-il ?" Tu es gentil, tu me demandes de prouver la conjecture de Syracuse... Je t'avoue que je ne sais pas le faire ! Je te laisse faire la démonstration. Tant que tu ne l'as pas faite, la question : "Pourquoi tous les impairs seraient ils dans ton arbre ?" est aussi vraie que la tienne (c'est-à-dire non démontrée).
Lis cela une bonne fois pour toutes : Personne ne sait pas si l'arbre de Collatz (ou le tien, qui revient au même) contient tous les impairs. Si on le savait, il n'y aurait plus de conjecture. Elle serait soit vraie (et tous les impairs seraient dans les deux arbres) ou fausse (et certains impairs ne seraient pas dans les deux arbres). Donc arrête s'il te plait avec tes intuitions ou autre baratin. Soit tu nous amènes une preuve de ce que tu avances, soit ça n'intéresse personne !
Merci pour le tableau mais ces correspondances ont été largement explorées sur le fil "Un modèle pour Syracuse" Sans que cela n'éclaire grand chose Ma conclusion est que les chemins, montées, descentes, etc.. ne servent à rien. C'est le folklore. Trouver une vraie règle de construction à l'arbre, sans recours au calcul de l'algorithme est ma piste perso. A laquelle personne ne croie
@PMF; Il n'est pas ,nécessaires d'espérer pour entreprendre ni de réussir pour persévérer, c'est bien connu, mais la croyance n'a jamais apporté une solution à un problème relevant des mathématiques?
@PMF : Je pars du principe que tu as bien compris que le premier chiffre à gauche (2 ici) est la relation au premier impair issu d'un 2^n, soit 1 pour 5, 2 pour 21, 3 pour 85, 4 pour 341, etc...
Le mot "complication" est décidément ce qui domine dans ce fil. Il existe une méthode très simple, qui consiste à calculer la séquence d'exposants de la suite donnée. Par exemple, la séquence d'exposants de 119 est 1, 1, 3, 4, 1, 3, 1, 2, 3, 4. Je rappelle que chaque terme représente $u$ dans $n_{i+1}=(3\,n_i+1)/2^u$. Lorsqu'on veut retrouver $n_0$ en partant de 1, on peut commencer par inverser la séquence (mais ce n'est qu'une question de praticité) : 4, 3, 2, 1, 3, 1, 4, 3, 1, 1. Ensuite on calcule $(1 \times 2^4-1)/3=5$, avant-dernier terme de la suite de 119, puis $(5 \times 2^3-1)/3=13$, etc.
Pourquoi ta méthode est-elle complexe, inefficace et peu fiable ?
Le dernier terme de la séquence est 4, 6, 8, ... selon que l'avant-dernier terme de la suite de $n_0$ est 5, 21, 85, ... En effet, $(3 \times 5+1)/2^4=1\;,\;(3 \times 21+1)/2^6=1\;,\;$etc. Toi tu décrètes que le dernier chiffre de ton code (avant inversion) est 1, 2, 3, ...
Lors d'une remontée à partir de 1, les termes de la séquence d'exposants doivent impérativement conserver leur parité. Tu peux remplacer 3 par 1 ou 5 mais pas par 2. Or, c'est exactement ce à quoi conduit l'opération consistant à diviser chaque terme de la séquence par 2 puis à prendre l'entier supérieur afin d'obtenir les chiffres du code. Le chiffre $3$ devient $\lceil 3/2 \rceil=2$, le chiffre $7$ devient $\lceil 7/2 \rceil=4$, etc.
Lors de la remontée utilisant ton code, la parité d'un chiffre peut être bonne ou mauvaise, ce qui t'oblige à tester. Si $c$ est ce chiffre et que $n_i$ est le terme de la suite calculé à l'étape précédente, tu poses $n_{i-1}=(n_i \times 2^c-1)/3$. Si le résultat est entier alors $n_{i-1}$ est le prédécesseur de $n_i$, mais si le résultat est fractionnaire alors $n_i$ n'a pas de prédécesseur et il faut inverser la parité de $c$ ; mais quelle est sa valeur ? Car pour retrouver le $n_0$ codé il faut nécessairement trouver la bonne valeur de $c$.
Tu vois que ta méthode ajoute de la lourdeur, de la complexité et de l'incertitude à ce qu'on savait déjà faire très facilement sans mettre en doute la validité du résultat.
Calcul de la séquence d'exposants de la suite de $n$ :
def exps(n):
lst = []
while n > 1:
q = 3*n+1
d = q & -q
n = q // d
lst.append(d.bit_length()-1)
return lst
print(exps(3439))
@PMF : lourran et Wilfrid, je veux bien être à des lustres de la grande compréhension mathématique qui est la vôtre
J'espère que tu connais un peu de Javascript : forum.user("Wilfrid").skill.maths = null
@Zgrb Merci pour ta réponse mais faut pas s'énerver non plus. Y a pas mort d'homme. Je note donc très précisément ce que tu as dit. Je n'en donne peut-être pas l'impression mais je trouve que tes réponses sont les meilleures de ce fil. Donc peu de chances de contourner les difficultés d'après toi. Reste qu'une partie de ce que je fais est surtout destiné à essayer de mieux décrire certains aspects (donc hors théorique). Le code de lignée est à mon avis une bonne idée, tout comme la position dans le tableau. Je pense qu'il faut oublier les entiers. On s'en fout de toutes les valeurs d'un chemin vers 1. On pourrait tout faire avec les codes de lignées en trouvant les bonnes règles de structure. Cela pourrait peut-être [être] moins "violent" que de se prendre en permanence le problème "en frontal". Reste que c'est bien difficile de faire ce codage car les cycles en jeu ne font pas vraiment de cadeaux.
Si j'ai bien compris vous voulez construire un arbre similaire à l'arbre de Collatz (est-ce que cela veut dire isomorphe, c'est-à-dire que chaque branchement se retrouve de l'un à l'autre indépendamment du contenu de chaque nœud et de chaque feuille) puis montrer que tous les arbres de ce type, quelle que soit la façon de le "remplir" contient tous les entiers, ou plus vraisemblablement que certaines familles de remplissages (dont Collatz) contient tous les entiers. Est-ce bien cela ?
Il ne faut pas respirer la compote, ça fait tousser.
J'affirme péremptoirement que toute affirmation péremptoire est fausse
@Wilfrid Tu calcules une séquence d'exposants et moi je fais un code de lignée. On ne fait pas la même chose, c'est tout. ton 119 est 1, 1, 3, 4, 1, 3, 1, 2, 3, 4. mon 119 est 1.2.1.1.2.1.2.2.1.1
Les deux ne servant pas à la même chose. Le code de lignée c'est une façon de se guider "visuellement" dans un arbre. Il parle de descendance. Il dit comme cette descendance s'est faite. C'est tout. Cette méthode ne crée strictement aucune erreur.
Si, on fait exactement la même chose : on cherche à retrouver un entier impair donné en remontant depuis 1. L'objectif qu'on poursuit est secondaire, ce qui importe dans le cas présent est la méthode utilisée. La différence entre toi et moi est que moi je suis réaliste et que je recherche toujours la solution la plus simple et la plus économique.
Je me fiche totalement de savoir comment tu obtiens tes lignées ou comment tu fais tes calculs. Donc tes exercices, je m'en moque.
Je redonne l'image : je vois un type qui construit une tour verticale partant de Brest, et qui prétend qu'il arrivera à New York en allant toujours tout droit vers le ciel.
Tant que tu n'auras pas de ligne directrice cohérente, tant que tu ne sauras pas où tu veux aller, tu vas enchaîner des calculs et des tableaux... tous ridicules.
Tu me dis, j'oublie. Tu m'enseignes, je me souviens. Tu m'impliques, j'apprends. Benjamin Franklin
Non on ne fait pas la même chose. Je me moque des chemins. La structure de l'arbre est mon objet d'étude. Si je pouvez me passer à 100% des entiers je le ferai. Je veux arriver à ne travailler qu'avec les codes de lignées comme s'ils étaient des entités indépendantes des entiers. Il y a des règles qui peuvent parfaitement définir comme l'arbre se construit. Ce sont des règles de descendance ou de reproduction (cycle, fertilité, stérilité, etc..) qui n'ont rien d'exceptionnelles.
Je reviens là-dessus. Compter le nombre de termes pairs entre deux termes impairs revient au même, en plus compliqué, que de lire la valeur du terme correspondant de la séquence d'exposants. Par exemple, ..., 101, 152, 76, 38, 19, ... équivaut à ..., 3, ...
Si on appelle $t$ un terme de la séquence d'exposants, et $c$ un chiffre du code, on a
$c=\lceil t/2 \rceil$
On ne peut pas modifier la parité d'un exposant, et donc, remonter vers $n_0$ sur la base de son code oblige à s'assurer à chaque étape que $c$ respecte cette parité. Comme on n'a aucun moyen de le savoir, le test revient à remplacer $c$ par $2\,c$ puis par $2\,c-1$ dans $n_{i-1}=(n_i \times 2^c-1)/3$ afin de savoir lequel des deux donne un résultat entier. On s'impose donc une triple conversion : $t \to c$ puis $c \to 2\,c$ et $c \to 2\,c-1$. Quel individu normalement constitué agirait de la sorte alors qu'il peut utiliser $t$ directement
@lourrran Je vais effectivement construire une tour à Brest. Elle suivra une trajectoire balistique jusqu'aux limites de l'espace et replongera en direction de New York où elle s'enracinera. En lui faisant faire une petite boucle à son apogée, des ascenseurs pourront circuler dans les deux sens sans que personne ne s'aperçoive de l'inversion. Ils auront l'impression de toujours aller dans le même sens comme dans un anneau de Moebius.
Maintenant que le problème architectural est réglé, je peux donc si tu le veux bien donner ma ligne directrice.
Ce n'est pas feu Paul Erdős qui dira le contraire : cette conjecture est-elle par essence un problème qui tourne en rond dans le logiciel mathématique ? Une sorte de boucle dont on ne peut sortir. C'est possible. En même temps, ce n'est jamais qu'un problème de générations et de descendances. Hors les maths, il y a une logique qui s'applique aussi. Donc l'idée est de démathétiser le problème en sortant des entiers. Construire un nouvel objet d'étude où on ne fait plus d'arithmétique. Mais évidemment il faut faire une correspondance solide avec la base de départ. Tu vas me dire que je tue le problème au lieu de le résoudre. Que ce transfert va ruiner la finesse du problème. Oui, mais on s'y noie dans cette finesse depuis des lustres. Alors....
Etape 1. De par les outils simples qui ont été décrits sur ce fil, un arbre peut se réduire à des objets ayant des relations entre eux. Je les appelle des codes de lignées mais on pourrait les nommer autrement. Le tout est de ne voir qu'un système qui se reproduit. Comme dans la nature, il y a un partage des tâches pour y arriver et surtout pas mal de contraintes. Ce système est aussi éternel et infini. Comme personne ne meurt, il grandit infiniment.
Etape 2. On oublie les pairs et les impairs, et tous ces chemins biscornus de montées et de descente. Il n'y a qu'une génèse d'objets à décrire. Un des premiers challenges est de construire une nouvelle orbite proprement en ne travaillant qu'avec les codes de lignées. Que se passe-t-il sur l'orbite précédente et comment va se construire la nouvelle? Qui apporte du sang neuf et qui ne le peut pas. Il y a des cycles, et des états de stérilité ou de fertilité. Donc un objet va suivre une histoire entre le moment où il apparait et celui où il devient la souche de toute une partie de l'arborescence. Dans ce système, l'adn est porté plus par le système que par les individus. Donc en fait tout est instantané même si la structure en orbites, assimilables à des générations. et donc qu'on pense un peu trop à une chronologie.
Etape 3. Imaginons que ce codage puisse fabriquer 1000 orbites, ou du moins décrire des morceaux d'orbites très lointaines. On va se demander si on aurait pu le faire avec l'algorithme. Et évidemment il faudra vérifier que ce qu'on fabrique dans un monde est toujours compatible avec l'autre. A terme on peut s'estimer satisfait et se dire que la structure de l'arbre est connue. Et tenter de décrire que certaines choses sont strictement impossibles (le fils est le père de son père semble impossible).
Donc je résume : Tu bâtis un codage avec des lignées, des orbites et tout un tas de trucs. Eventuellement, en cours de recherche, tu vas inventer 3 ou 4 nouveaux mots pour décrire ce codage. Ou pour faire durer l'histoire. Ce codage est basé sur le chemin qui part d'un entier quelconque et qui va jusqu'à 1. Ce codage permet de coder tous les nombres qui aboutissent à 1 par l'algorithme de Syracuse.
On cherche à ne plus parler d'entiers ou de nombres ... donc on va dire de façon un peut différente : ce codage permet de coder tous les individus qui sont reliés à 1 par l'algorithme de Syracuse.
Donc pour tous ces individus là, tous ceux qu'on a su coder, tous ceux qui sont des descendants de 1, tu dis qu'on devrait pouvoir exhiber des résultats. En particulier, on devrait pouvoir prouver que parmi tous les descendants de 1, on n'a aucune configuration du type "le fils est le père de son père"
Oui ... mais ça on le sait déjà : parmi les descendants de 1, il n'y a pas de cycle. C'est d'une banalité sans nom. Et même mieux, puisque tu veux démontrer des banalités : on sait déjà que parmi les descendants de 1, tous les nombres sont des descendants de 1.
Tu me dis, j'oublie. Tu m'enseignes, je me souviens. Tu m'impliques, j'apprends. Benjamin Franklin
Oui, c'est bien l'idée. Trouver le principe de construction, le squelette, l'organisation hiérarchique, etc... Donc isomorphe comme vous le dites, oui évidemment. X est le père de y qui est le père de z... On n'a pas besoin des entiers pour cette relation. Quand on parle de parents, d'enfants, de fratrie, non plus. Donc la première idée est de sortir l'organisation logique de l'arbre du contexte arithmétique en essayant bien sûr que les règles logiques soient compatibles.
Evidemment pour la question du "remplissage" c'est moins évident. On pourrait calculer éternellement pour montrer que ce remplissage fonctionne. Sauf qu'il faut calculer un arbre de millions voire milliards d'éléments pour avoir une suite remplie de 1 à 27 !
En tout cas, tout ce qui concerne ce "remplissage" est une des clés de cet arbre. On voit par exemple très vite le phénomène de "clusterisation" quand la population d'entiers présents dans l'arbre a tendance à se regrouper. Ce n'est pas aléatoire et très typique de Collatz.
L'impression que cela donne est que vous voulez remplacer une difficulté par 3 difficultés au moins de même envergure.
1) Définir l'arbre de Collatz sans utiliser Collatz. 2) Définir les façons acceptables de remplir cet arbre (qui doit contenir Collatz). 3) Prouver qu'avec toutes les façons acceptables, l'arbre contient IN
Il ne faut pas respirer la compote, ça fait tousser.
J'affirme péremptoirement que toute affirmation péremptoire est fausse
@Médiat_Suprème Votre résumé est 3 points est correct Je le précise donc en reprenant la même numérotation :
1) Dans le nouvel arbre que l'on peut appeler généalogique, un objet dit "code de lignée" remplace l'entier. Cet objet est un point de l'arborescence et ne contient rien d'autre que sa position dans l'arbre et l'information généalogique. La méthode de conversion d'un entier en code de lignée est un algorithme qui ne produit qu'un seul résultat. Il n'y a qu'un entier à une position donnée de l'arbre et donc un seul code de lignée. Arbre généalogique et arbre de Collatz sont homogènes.
2) La première façon de transformer un arbre de Collatz en arbre généalogique (ou arbre structurel) consiste à traduire tous les entiers impairs qu'il contient en codes de lignée. Cet arbre est donc à ce stade strictement semblable à son original mais totalement dépendant de l'algorithme de Collatz. Son intérêt est de servir d'objet d'étude pour définir les règles de construction indépendantes. Ces règles reposent sur un principe fondamental de reproduction. Le système est certes reproductible à l'infini mais il est régulé par des contraintes : cycle de reproduction et éléments stériles. N'importe quel code de lignée ne trouve donc pas sa place dans l'arbre. Quand ces règles sont acquises, un nouvel algorithme peut générer directement l'arbre. On peut considérer ici que la difficulté est surtout technique : trouver les bonne règles et les traduire correctement dans un code.
3) Quand le code de l'arbre généalogique est au point, on peut vérifier que la conversion des codes de lignée en entiers (l'algorithme est dispo) donne pour n orbites demandées un arbre de Collatz. Mais il faut savoir qu'un arbre d'une centaine d'orbite (nombre assez bas) contient déjà des milliards d'éléments. Les limites de calcul vont donc être vite atteintes. Pour des tests plus poussés, on peut générer un code de lignée correspondant à une orbite très grande et vérifier que l'entier correspondant est bien au bon endroit dans l'arbre de Collatz (notons ici que la conversion du code de lignée donne le chemin complet vers 2^n). Néanmoins ce seront toujours des vérifications par calcul. Mais je dis qu'à ce stade, les règles de l'arbre peuvent être étudiées c'est-à-dire que cette structure ne peut logiquement contenir que certaines formes d'arborescence et pas d'autres. Et la question sera : comment un entier peut-il ne pas appartenir à un arbre de Collatz puisque le propre d'un entier est d'être l'aboutissement d'une arborescence ? Si je disais que je peux créer un code de lignée sans arborescence, ce serait idiot puisque que ce code est un pur produit d'une arborescence. Il faut démontrer que c'est la même chose avec un entier.
@Médiat_Suprème Précision importante sur ma définition d'un arbre de Collatz. Je me base sur une formulation alternative de la conjecture : Soit i un impair et i' celui que l'on obtient après n itérations de l'algorithme tel que i' = i*3+1/2^n En répétant ce processus, on arrive à un i' tel que i'*3+1= 2^n Le plus petit 2^n de l'arbre est 2^4 associé à l'impair 5. De ce fait le code de lignée de 5 est "1." (21 est "2." 85 est "3." etc...) Les codes de lignée ne correspondent donc qu'à des impairs. Les pairs sont toujours de la forme i*2^n et i étant défini par un code de lignée il est inutile de les définir à leur tour.
Il faudra donc 1) Définir les "codes de lignées" sans allusion à Collatz et démontrer que Collatz n'est qu'un cas particulier. 2) "Trouver les bonnes règles" n'est pas une difficulté technique. 3) Il n'y a pas de problème de limite de calcul, puisqu'il faut démontrer pour tous les entiers (et pas seulement sur quelques-uns).
Il ne faut pas respirer la compote, ça fait tousser.
J'affirme péremptoirement que toute affirmation péremptoire est fausse
Réponses
Oui comme tu le décris effectivement, le cartographe de cette époque n'imagine pas autre chose que ce qu'il connait.
Il ne pourra jamais prévoir les découvertes non plus. Remarque que ce n'est pas son taf.
Je comprends bien que l'inconnu non cartographié, c'est dans le sens de ta métaphore les cycles triviaux, etc. Il n'y a rien dans l'arbre existant qui puisse en donner un signe annonciateur (ça n'empêche pas de chercher un peu, mais bon)
Ton argument est costaud, et je le reconnais dur à contrer. On pourrait quand même dire deux choses :
1) A ce moment de l'histoire, avant l'arrivée d'un Christophe Colomb de l'arithmétique qui va tout chambouler, l'arbre-carte n'est pas par terre. Des machines continuent à explorer les bords de ce monde, rien de bouge. Hypothèse de la stabilité : ça peut continuer comme ça. Beaucoup le pensent.
2) Mais on doit admettre qu'il peut y avoir une découverte bouleversante. Cela peut venir du calcul ou d'une démonstration. Personne ne sait.
Je ne prétends pas trancher un dilemme pareil. Comme je suis plutôt un "stabiliste" je cherche plutôt à montrer le caractère stable de l'arbre. On peut montrer que la structure de l'arbre élaborée sur des règles de construction indépendantes de l'algorithme peut produire toutes les positions nécessaires et venir infiniment "matcher" la position potentielle d'un entier dont théoriquement personne n'a jamais vérifié le chemin.
Imagine que mon programme puisse écrire un code de lignée qui remplirait des pages et des pages. Le programme dirait qu'il n'a aucune idée de l'entier qu'il représente mais que la position est fiable. On peut ainsi prouver que même pour des entiers très très grands, il y a toujours une position dans l'arbre.
Cette position est bien plus facile à décrire et on peut prouver qu'elle est viable si on a démontré que les règles sont logiques.
349525 est le neuvième départ de branche depuis les puissances de 2 : il provient de 2^20
L'arbre a un nombre fini d'orbites au moment où quelqu'un y cherche quelque chose.
Mais évidemment l'arbre a un nombre infini d'orbites, et tant qu'on ne cherche pas à le représenter, il est infini.
Je rectifie un peu ta phrase : Je remplace juste le mot 'des' par le mot 'certains' , ça ne change quasiment rien, mais je préfère. Obsession de matheux. Parfois le mot des est mal interprété, alors que le mot certains laisse beaucoup moins de doutes.
Imagine que mon programme puisse écrire un code de lignée qui remplirait des pages et des pages. Le programme dirait qu'il n'a aucune idée de l'entier qu'il représente mais que la position est fiable. On peut ainsi prouver que même pour certains entiers très très grands, il y a toujours une position dans l'arbre.
Maintenant, reprenons cette dernière phrase : On peut ainsi prouver que même pour certains entiers très très grands, il y a toujours une position dans l'arbre.
Soit, et alors ? Tu veux prouver à ton tour un truc qui est connu, admis, prouvé depuis plus de 60 ans ? Un truc qu'on peut prouver en 3 minutes quand on entend parler de cette conjecture pour la 1ère fois. C'est ça ton challenge ?
"C'est ça ton challenge ?"
Mon challenge est de construire un arbre sans l'algorithme de Collatz en se basant sur des règles qui génèrent une arborescence identique.
Voilà par exemple un code de lignée un peu particulier
1.2.1.1.1.2.1.1.1.2.1.1.2.1.1.2.1.1.1.2.2.1.1.2.2.1.1.1.1.2.2.2.2.1.2.2.2
Ce code est intéressant parce qu'on ne peut pas écrire un code aussi long avec aussi peu de 2. Par l'effet complexe des cycles de multiples de 3 qui donnent des impairs sans descendance, il n'est pas possible d'écrire un code comme 1.1.1.1.1.1.1.1.1.1.1.... parce que ça n'existe pas dans l'arbre. Il faut composer avec des deuxièmes descendants toutes les fois où le premier est stérile.
pour info, ce code de lignée est l'itinéraire vers 105 892 338 373
On peut ainsi prouver que même pour certains entiers très très grands, il y a toujours une position dans l'arbre.
Mon challenge est de construire un arbre sans l'algorithme de Collatz en se basant sur des règles qui génèrent une arborescence identique.
Et cet arbre permettra de prouver un résultat qu'on peut prouver par ailleurs en 3 minutes.
Je réponds à ce message.
Si je comprends bien ta méthode, supposons que tu veuilles coder l'entier impair $n$ :
Tu calcules la suite standard (avec les termes pairs) de $n$, puis tu l'inverses.
Tu cherches un 16 et à partir de lui tu comptes le nombre d'étapes paires jusqu'au premier terme impair. As-tu prévu le cas où le 16 ne serait pas égal à $3 \times 5+1$ mais à $(3 \times 85+1)/2^4$, ce qui n'est pas du tout la même chose ?
Tu divises ce nombre d'étapes par 2 et tu arrondis à l'entier supérieur. Pourquoi ? Qu'est-ce qui justifie cette opération ?
Tu cherches le nombre d'étapes jusqu'aux termes impairs suivants, et tu appliques à chacun la même opération.
Je reprends ton exemple de $n=368223$ (les impairs sont en gras) :
1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144, 524288, 1048576, 349525, 699050, 1398100, 2796200, 5592400, 1864133, 3728266, 1242755, 2485510, 828503, 1657006, 552335, 1104670, 368223
de 16 à 349525 : $\lceil 17/2 \rceil=9$
jusqu'à 1864133 : $\lceil 4/2 \rceil=2$
puis 4 fois $\lceil 1/2 \rceil=1$ pour arriver à 368223.
Résultat : 368223 est codé 9.2.1.1.1.1.
Maintenant, disons qu'on veuille retrouver 368223 à partir de ce code. Comment fait-on ? C'est d'autant plus compliqué que le code 1, par exemple, peut être interprété de 2 manières : $\lceil 1/2 \rceil$ ou $\lceil 2/2 \rceil$. De la même manière, le code 9 peut correspondre à $\lceil 18/2 \rceil$ ou $\lceil 17/2 \rceil$. Dans ces conditions, tu ne peux pas savoir quel est le bon exposant de 2 à appliquer à chaque étape de la remontée vers $n$, puisqu'à chaque fois tu as deux possibilités.
Il est bien sûr possible de retrouver l'entier depuis son code de lignée
Je publierai la méthode cet apm
Sinon pour 16 : la toute première bifurcation de l'arbre est 16--->32 ou 5
De ce fait quelque soit l'orbite où se trouve un entier , son chemin reviendra à 16 soit par la porte 32, soit par 5
Donc dans ma série, 16 remplace le 1 comme point d'arrivée
Je ne comprends pas ce que tu écris. Si on s'en tient aux prédécesseurs de 1 non multiples de 3, qui donc possèdent des prédécesseurs, c'est-à-dire 5, 85, 341, 5461, 21845, ..., on trouvera 16 en effectuant les opérations suivantes :
$3 \times 5+1$
$(3 \times 85+1)/2^4$
$(3 \times 341+1)/2^6$
$...$
Dans le premier cas il existe effectivement une bifurcation, en l'occurrence 5 puisqu'il possède une infinité de prédécesseurs impairs vers lesquels on peut bifurquer. Mais lorsque la suite ne passe pas par 5, le 16 en question ne correspond pas à une bifurcation.
Exemple : ..., 85, 256, 128, 64, 32, 16, 8, 4, 2, 1. Tu t'es focalisé sur 5 en tant qu'avant-dernier terme de la suite, mais ce n'est qu'un cas parmi d'autres, bien qu'il soit le plus répandu. Prenons deux suites :
A : 111, ..., 53, 5, 1
B : 113, 85, 1
Dans le cas de A, le premier chiffre du code sera le nombre d'étapes paires séparant 53 de 5 (avant division par 2). Dans le cas de B, ce sera le nombre d'étapes paires séparant 85 de 16, ce qui fait que 85 n'est plus considéré comme un des prédécesseurs directs de 1 mais comme le premier terme impair rencontré lors de la remontée, alors que logiquement ce devrait être 113. Tu trouves ça cohérent ? Eh bien ça ne l'est pas !
Voyons maintenant comment tu fais pour retrouver le premier terme d'une suite à partir de son code. Je suis impatient !
Pour faire des 'économies', il arrête le chemin à 16. Avant, il l'arrêtait au dernier impair.
Le nombre 1 ne peut pas s'écrire dans ce modèle, il n'existe pas.
Je sais, je chipote. Ce problème n'est pas catastrophique.
On a une voiture qui n'a pas de roues et pas de moteur, on a oublié l'essieu avant, le châssis est vraiment de mauvaise qualité, et je suis en train de critiquer parce que le gris du tableau de bord est un peu trop clair.
@lourrran
Un coup d'oeil sur ce tableau svp. C'est le début de l'arbre tel que l'écrit mon script vba (déjà publié 2 fois)
Que voyez-vous ?
Que l'arborescence débute après la ligne "16" avec la ligne "32, 5" : c'est la première fois où on a 2 résultats possibles 16*2 ou 16-1/3
Comme tout chemin partant de 1 passera par 32 ou 5, 16 est le point de repère du code de lignée
Il serait aussi juste de dire que tout entier transformera un impair i via x itérations i*2n+1/3 jusqu'à ce que 3i+1 = 2^n : la solution du chemin est trouvée à ce moment. Selon le n obtenu, on aura le premier numéro de lignée en calculant 0,5*n-1
Mais ce n'est pas assez frappant de dire que l'algorithme finit toujours par ramener un entier à une puissance de 2 plutôt qu'à 1
La souche de l'arborescence, le point d'ancrage de la hiérarchie c'est 2^4
Remplir un arbre, pour le plaisir de remplir un arbre, pourquoi pas. On remplit un arbre, au même titre qu'un gamin ferait du coloriage. C'est cool, ça passe le temps, et ça n'a aucun objectif 'scientifique'.
Remplir un arbre pour démontrer que l'arbre de Collatz peut contenir des entiers très grands (c'est l'objectif que tu as annoncé), c'est clownesque.
la façon dont je procède pour retourner un entier depuis un code de lignée est la suivante
Voici le code de lignée que nous allons décoder : 4.3.2.2.2.1.1
On traduit toujours de gauche à droite donc ici on part de x = 4 pour trouver l'ancêtre
n = 2x+2 = 10
l'ancêtre est 2^n-1/3 = 341
Maintenant on peut continuer en utilisant le rang r du descendant i' de 341 (qu'on appellera i)
Dans excel la formule de i' c'est ça :
=SI(MOD(i*2^(2*r)-1;3)=0;(i*2^(2*r)-1)/3;(i*2^(2*r-1)-1)/3)
Que l'on peut expliquer comme : si le modulo 3 de (i*2^(2*r)-1 est 0, alors calcule (i*2^(2*r)-1)/3; sinon calcule (i*2^(2*r-1)-1)/3)
On fait donc l'opération avec i = 341 et la valeur suivante du code de lignée qui est 3 : i' = 3637
On refait la même opération avec i = 3637 et la valeur suivante du code de lignée qui est 2 : i' = 19397
On refait la même opération avec i = 19397 et la valeur suivante du code de lignée qui est 2 : i' = 51725
On refait la même opération avec i = 51725 et la valeur suivante du code de lignée qui est 2 : i' = 137933
On refait la même opération avec i = 91955 et la valeur suivante du code de lignée qui est 1 : i' = 61303
Vérif
Sans vouloir entamer un procès en propriété intellectuelle, j'ai fait de A à Z ce script VBA qui construit l'arbre.
Nos avons échangé des scripts pendant le fil "Un modèle pour Syracuse" mais celui-ci n'en fait pas partie, même si tu pourras toujours y retrouver des similitudes. Dans un script concernant Collatz, on va toujours trouver des 3n+1/2^n entre autres. Et puis forcément on va aller dans un sens ou dans un autre selon que l'on utilise l'algorithme ou son inverse.
Si je peins un tableau avec des ronds rouges, tous les tableaux avec des ronds rouges ne sont pas les miens.
Tu peux critiquer mon travail s'il ne te plait pas mais pas de dire que quelque chose t'appartient si ce n'est pas vrai.
On va comparer un arbre de Collatz avec un arbre généré par l'algorithme simplifié (qui ne contient pas la multiplication par 3). On va ensuite montrer que ces deux arbres ont fondamentalement la même structure. Comme on montre que l'arbre de l'algorithme simplifié contient tous les entiers naturels, la question se pose de savoir pourquoi un autre arbre de même structure ne pourrait pas en faire autant. Où est donc exactement leur différence ?
1) l'arbre généré par l'algorithme simplifié (ou arbre simplifié)
On construit cet arbre presque de la même manière que celui de Collatz: on double toutes les valeurs de la ligne précédente et on ajoute à la fin de cette nouvelle ligne i+2, i étant l'impair situé en fin de la ligne précédente.
Dans l'arbre, chaque colonne ne contient qu'un impair (une nouvelle colonne = un nouvel impair). Tous les impairs sont situés sur la diagonale qui borde le coté droit. Les puissances de 2 sont en première colonne. Toutes les autres valeurs du tableau sont des pairs de la forme i*2^n.
Ces points sont identiques à l'arbre de Collatz.
2) L'arbre simplifié contient tous les entiers
On va prendre la suite arithmétique de 1 à 32 contenue dans cet arbre. Chaque nouvelle colonne débutant par i+2, il faut 32/2 = 16 colonnes et 16 lignes pour arriver à l'impair 31 en bas à droite. Nous avons donc toute la suite impaire de 1 à 31
Comme la colonne 1 contient les puissances de 2 jusqu'à 2^15 (exposant = n° de ligne -1),nous avons donc 2,4,6,8,16,32
Il ne manque donc que les pairs de forme i*2^n <32 que nous trouvons évidemment associés aux colonnes contenant les impairs i de 3 à 15 (en bleu)
Le plus grand i*2^n est 30. Il est issu de 15 qui se trouve en colonne et ligne 8. Il reste donc pour 15 la possibilité d'atteindre 15*2^9 en dernière ligne, valeur largement au-dessus de 30. Tous les autres i*2^n devant atteindre une valeur plus basse que 30 et étant situés plus haut dans la tableau, la série 6, 12, 24, 10, 20, 14, 28, 18, 22, 26, est complétée.
Un arbre de n colonne contient donc une valeur impair maximale impaire i = 2n-1, et toute la suite de 1 à i+1 est incluse dans cet arbre.
Cet arbre contient donc tous les entiers.
On arrive ici à une deuxième équivalence avec l'arbre de Collatz : les entiers pairs y sont surreprésentés. De même pour compléter la suite 1 à 32, il faut générer 136 éléments dont la valeur maximale est 49152. Un arbre de Collatz présente ce même défaut de "surconsommation" puisque l'on a vu que la série de 1 à 27 implique un arbre de Collatz qui contiendrait des milliards d'éléments. Mais c'est la même propriété : une petite série demande un grand tableau.
3) Où est la différence?
Il y a une seule différence entre ces arbres : les impairs dans l'arbre de Collatz n'arrivent pas dans l'ordre des colonnes. Voyons ce que peux donner un arbre de Collatz en réordonnant les impairs :
Nous avons là "à la mode Collatz" la série des impairs de 1 à 26 (cad avant le fameux 27 qui demanderait de calculer des millions de colonnes).
La suite des entiers de 1 à 26 est contenue dans ce tableau exactement comme dans le cas de l'arbre simplifié
Alors bien rangé notre arbre de Collatz est-il le même qu'un arbre simplifié ?
La différence est bien sûr que nous perdons l'alignement décroissant des colonnes (en diagonale pour l'arbre simplifié, en courbe pour Collatz). Rappelons aussi que pour avoir ce tableau il faut calculer 24 lignes et 143 colonnes. Voici les positions pour i de 3 à 25 dans l'arbre :
Cela parait si simple d'associer un i avec ses coordonnées (ligne, colonne). Construire un arbre, c'est à la fois générer toutes les descendances que l'on traduira avec les codes de lignées et de ce fait obtenir une position (ligne, colonne) pour chaque impair du tableau.
Il ne serait pas impossible de construire directement un tel tableau dans l'ordre des impairs. Tout le problème, on l'aura compris, c'est de positionner chaque impair sur la bonne ligne. Or ce résultat dépend de la construction intégrale de l'arbre ou de générer pour chaque impair les itérations i*2n+1/3 jusqu'à ce que 3i+1 = 2^n. On repère alors ce 2^n dans la colonne 1 et on place le i une ligne plus bas. La colonne se remplit ensuite avec les i*2^n.
C'est donc certainement faisable en code mais la question est : pourquoi cette possibilité technique très simple (placer un i sur sa ligne et passer à i+2) ne peut-elle se répéter jusqu'à l'infini ? Dans l'infini des combinaisons (l,c) de i, il en existerait un qui serait sans coordonnées.
4) conclusion pratique
Si on ne peut trancher en théorie sur le i introuvable dans l'arbre, il est possible de faire un code efficace qui produirait des données dans le format suivant :
Vous n'avez malheureusement pas pris le temps de lire attentivement les quelques messages vous démontrant les contre-sens que vous faites dans le modèle de pensée que vous vous êtes construit concernant cette conjecture. Votre "perception", ou "conception" de la conjecture est erronée, et tant que vous ne changerez pas cela, vous ne pourrez avancer.
Bonne continuation !
Remets-en une couche de mauvaise foi si tu veux, mais puisque tu aimes tant me citer tu aurais pu noter que mon mail commence par :
"Sans vouloir entamer un procès en propriété intellectuelle, "
Si je mets un code VBA sur un fil, c'est que je me moque de la propriété intellectuelle puisque je le donne ! Mais je peux encore dire que je l'ai fait.
Ton attitude sur ce fil n'est pas très cool. L'ironie c'est bien, et tu es libre de ne pas apprécier ce que je dis, même si c'est un peu systématique. Et puis à un moment ton ironie devient mensonge et tu déformes mes propos. Pour moi ça tourne au forum à deux boules comme il y en a partout sur le net.
C’est triste, c’est toi qui dit à lourrran cette phrase.
Tu réponds toujours par des graphiques et des romans.
À bon entendeur (même s’il se bouche les oreilles) !
Je ne comprends pas ton attitude. Tu as commencé par des questions du type "la question que je te pose, et à la réponse que tu feras je te dirais que tu ne m'auras pas répondu"...Donc ta question comporte sa propre stratégie rhétorique : on a fait mieux et plus subtil pour convaincre.
Je t'ai toujours répondu mais dans le style qui est le mien. Publier des graphiques est aussi une preuve de travail. C'est une façon de penser. Pour les romans, excuse-moi mais j'ai un peu de mal avec la stylistique SMS.
Oui je ne m'exprime pas de la façon habituelle pour parler de mathématique. Cela ne veut pas dire que ce soit incompréhensible.
Donne-moi une fois stp un retour précis et pas des généralités : peux-tu me dire par exemple ce que tu penses de la comparaison que j'ai faite ce matin entre un arbre simplifié et un arbre de Collatz ? Penses-tu que l'absence d'ordre (ou du moins l'ordre très particulier) de l'apparition des impairs dans l'arbre serait la condition qu'un entier un jour ne puisse y entrer? Ou alors comme je le crois, quelque quoi que soit cet ordonnancement, au final tout impair trouvera sa place dans l'arbre. Et ne me dis pas que tu ne comprends pas ce texte en 4 points, précédés d'un résumé, et illustré des graphiques qui sont indispensables.
Les questions intéressantes, c'est : où comptes- tu aller, comment comptes-tu arriver à tel ou tel objectif.
Soit tu ne réponds pas à ces questions, soit tu y réponds, et alors, il devient évident que tu n'as rien compris au problème et aux difficultés dans la notion "d'infini dénombrable"
Imagine un type qui dit qu'il veut construire un pont de Brest à New-York.
Et pour ça, il achète un terrain près de Brest, et il construit une tour très haute, et quand on l'interroge, il dit qu'en construisant une tour très très haute, il arrivera à New-York.
Et le type dit : vous voyez bien que je travaille beaucoup.
Lis ensuite ta réponse qui au mieux tourne autour d’un pot que je ne visualise pas ou qui de mon point de vue montre un manque de respect évident : tel un politique qui dis « je réponds » mais qui ne répond pas. Du mépris dit-on parfois.
Quelques phrases en bon français permettraient à tes malheureux lecteurs de dégager une philosophie, une idée directrice. Même les grands s’y prêtent.
On est samedi, il y a un beau ciel bleu: tu penses bien que personne ne va se plonger dans un fouillis de colonnes chiffrées sans même être sûr que ça mène quelque part. D’autant que tout le monde est persuadé que ça ne mène nulle part (ni à Brest, ni à New York).
Tu es un illusionniste. Le choix de tes exemples et la confusion de tes explications te permettent de créer l'illusion que l'impossible est possible.
Peux-tu me dire quel nombre est codé 2.2.1.1.2.1.2.2.1.1
1) simplicité : utiliser l'algorithme dont on a supprimé la multiplication par 3 pour générer un arbre simplifié. Cet arbre englobe tous les entiers.
2) complexité : utiliser l'algorithme classique de Collatz. Même s'il ressemble sur de nombreux points à un arbre simplifié, la complexité de la répartition des impairs ne peut garantir que tous peuvent intégrer l'arbre.
3) impossibilité : en modifiant l'algorithme avec d'autres facteurs que 3, l'expérience montre vite que les suites divergent.
Donc le choix de facteurs (*1, *3, *i>3), pourtant très simples paramètres de cet algorithme, nous fait passer de la simplicité, à la complexité puis à l'impossibilité. Ce réglage ne tient donc qu'à un fil.
2.2.1.1.2.1.2.2.1.1 ?
Je pars du principe que tu as bien compris que le premier chiffre à gauche (2 ici) est la relation au premier impair issu d'un 2^n
soit 1 pour 5, 2 pour 21, 3 pour 85, 4 pour 341, etc...
Aie!!! 2 renvoie à 21 qui est un multiple de 3. Il ne peut avoir de descendance donc tout le reste du code est impossible
Etait-ce une question piège ?
Sans prétention aucune, mon français me semble très correct.
Est-ce que tu comprends la comparaison que j'ai faite entre un arbre simplifié et un arbre de Collatz en transformant le *3 de l'algorithme en *1.
Qu'est-ce que vous avez tous avec les tableaux et les données ? Ce n'est pas assez théorique ?
C'est pourtant la réalité.
Désolé mais je réponds par des questions.
Que penses-tu de la comparaison entre arbre simplifié et arbre de Collatz? Pourquoi sont-ils si semblables et quel est pour toi le vrai marqueur de complexité dans celui de Collatz? Pourquoi tous les impairs ne finiraient-ils par trouver une valeur de colonne et de ligne, une position toute simple dans un arbre aussi grand soit-il?
Puisque PMF persiste à nous combler de tableaux je ne peux résister à lui présenter les trois tables suivantes représentant le début de la table de Collatz pour le cas d'origine 3x+1, pour le cas 3x-1 et pour le cas 3x+5.
Je lui laisse découvrir ces tables
A plus
@Wilfrid
Je veux bien être à des lustres de la grande compréhension mathématique qui est la votre, mais ce que je fais dans Excel est correct.
Allez comme vous êtes les deux seuls à l'utiliser, on passe aux exercices pratiques :
Exo : Retourner un entier depuis un code de lignée
Dans un tableau de A1 entre n°, puis de A2 à A12 entrer la suite 1 à 11
en B1 taper 5 pour faire simple
en B2 entrer : =SI(MOD($B$1*2^(2*A2)-1;3)=0;($B$1*2^(2*A2)-1)/3;($B$1*2^(2*A2-1)-1)/3)
attention il faut bien mettre des caractères "$" avant b et 1: taper bien "dollar" B "dollar" 1 (l'affichage le vire)
copier B2 de B3 à B12
en face de 1,2,3,4... s'affichent 3, 13, 53, 213... Vous avez tous les descendants du 5 par ordre d'apparition.
Astuce maintenant : taper 1 en B1
en face de 1,2,3,4... s'affiche 5, 21, 85, 341... Sympa non, tous les premiers impairs directement ici de 2^n
Bon essayons maintenant de traduire 1.2.1.3.1.5
"1." : je tape 1 en B1 : la concordance de 1 est 5
"2." : j'entre 5 en B1 : la concordance de 2 est 13
"1." : j'entre 13 en B1 : la concordance de 1 est 17
"3." : j'entre 17 en B1 : la concordance de 3 est 181
"1." : j'entre 181 en B1 : la concordance de 1 est 241
"5." : j'entre 241 en B1 : la concordance de 5 est 82261
PS : les impairs multiples de 3 renvoient des résultats décimaux. C'est normal. On ne rentre pas de pairs en B1.
Pour ta dernière question :
"Pourquoi tous les impairs ne finiraient-ils par trouver une valeur de colonne et de ligne, une position toute simple dans un arbre aussi grand soit-il ?"
Tu es gentil, tu me demandes de prouver la conjecture de Syracuse... Je t'avoue que je ne sais pas le faire !
Je te laisse faire la démonstration.
Tant que tu ne l'as pas faite, la question : "Pourquoi tous les impairs seraient ils dans ton arbre ?" est aussi vraie que la tienne (c'est-à-dire non démontrée).
Lis cela une bonne fois pour toutes :
Personne ne sait pas si l'arbre de Collatz (ou le tien, qui revient au même) contient tous les impairs. Si on le savait, il n'y aurait plus de conjecture. Elle serait soit vraie (et tous les impairs seraient dans les deux arbres) ou fausse (et certains impairs ne seraient pas dans les deux arbres).
Donc arrête s'il te plait avec tes intuitions ou autre baratin. Soit tu nous amènes une preuve de ce que tu avances, soit ça n'intéresse personne !
Merci pour le tableau mais ces correspondances ont été largement explorées sur le fil "Un modèle pour Syracuse"
Sans que cela n'éclaire grand chose
Ma conclusion est que les chemins, montées, descentes, etc.. ne servent à rien. C'est le folklore.
Trouver une vraie règle de construction à l'arbre, sans recours au calcul de l'algorithme est ma piste perso. A laquelle personne ne croie
Il n'est pas ,nécessaires d'espérer pour entreprendre ni de réussir pour persévérer, c'est bien connu, mais la croyance n'a jamais apporté une solution à un problème relevant des mathématiques?
Le mot "complication" est décidément ce qui domine dans ce fil. Il existe une méthode très simple, qui consiste à calculer la séquence d'exposants de la suite donnée. Par exemple, la séquence d'exposants de 119 est 1, 1, 3, 4, 1, 3, 1, 2, 3, 4. Je rappelle que chaque terme représente $u$ dans $n_{i+1}=(3\,n_i+1)/2^u$. Lorsqu'on veut retrouver $n_0$ en partant de 1, on peut commencer par inverser la séquence (mais ce n'est qu'une question de praticité) : 4, 3, 2, 1, 3, 1, 4, 3, 1, 1. Ensuite on calcule $(1 \times 2^4-1)/3=5$, avant-dernier terme de la suite de 119, puis $(5 \times 2^3-1)/3=13$, etc.
Pourquoi ta méthode est-elle complexe, inefficace et peu fiable ?
Le dernier terme de la séquence est 4, 6, 8, ... selon que l'avant-dernier terme de la suite de $n_0$ est 5, 21, 85, ... En effet, $(3 \times 5+1)/2^4=1\;,\;(3 \times 21+1)/2^6=1\;,\;$etc. Toi tu décrètes que le dernier chiffre de ton code (avant inversion) est 1, 2, 3, ...
Lors d'une remontée à partir de 1, les termes de la séquence d'exposants doivent impérativement conserver leur parité. Tu peux remplacer 3 par 1 ou 5 mais pas par 2. Or, c'est exactement ce à quoi conduit l'opération consistant à diviser chaque terme de la séquence par 2 puis à prendre l'entier supérieur afin d'obtenir les chiffres du code. Le chiffre $3$ devient $\lceil 3/2 \rceil=2$, le chiffre $7$ devient $\lceil 7/2 \rceil=4$, etc.
Lors de la remontée utilisant ton code, la parité d'un chiffre peut être bonne ou mauvaise, ce qui t'oblige à tester. Si $c$ est ce chiffre et que $n_i$ est le terme de la suite calculé à l'étape précédente, tu poses $n_{i-1}=(n_i \times 2^c-1)/3$. Si le résultat est entier alors $n_{i-1}$ est le prédécesseur de $n_i$, mais si le résultat est fractionnaire alors $n_i$ n'a pas de prédécesseur et il faut inverser la parité de $c$ ; mais quelle est sa valeur ? Car pour retrouver le $n_0$ codé il faut nécessairement trouver la bonne valeur de $c$.
Tu vois que ta méthode ajoute de la lourdeur, de la complexité et de l'incertitude à ce qu'on savait déjà faire très facilement sans mettre en doute la validité du résultat.
Calcul de la séquence d'exposants de la suite de $n$ :
J'espère que tu connais un peu de Javascript : forum.user("Wilfrid").skill.maths = null
Merci pour ta réponse mais faut pas s'énerver non plus. Y a pas mort d'homme.
Je note donc très précisément ce que tu as dit. Je n'en donne peut-être pas l'impression mais je trouve que tes réponses sont les meilleures de ce fil.
Donc peu de chances de contourner les difficultés d'après toi. Reste qu'une partie de ce que je fais est surtout destiné à essayer de mieux décrire certains aspects (donc hors théorique). Le code de lignée est à mon avis une bonne idée, tout comme la position dans le tableau. Je pense qu'il faut oublier les entiers. On s'en fout de toutes les valeurs d'un chemin vers 1. On pourrait tout faire avec les codes de lignées en trouvant les bonnes règles de structure. Cela pourrait peut-être [être] moins "violent" que de se prendre en permanence le problème "en frontal". Reste que c'est bien difficile de faire ce codage car les cycles en jeu ne font pas vraiment de cadeaux.
J'affirme péremptoirement que toute affirmation péremptoire est fausse
Tu calcules une séquence d'exposants et moi je fais un code de lignée. On ne fait pas la même chose, c'est tout.
ton 119 est 1, 1, 3, 4, 1, 3, 1, 2, 3, 4.
mon 119 est 1.2.1.1.2.1.2.2.1.1
Les deux ne servant pas à la même chose. Le code de lignée c'est une façon de se guider "visuellement" dans un arbre. Il parle de descendance. Il dit comme cette descendance s'est faite. C'est tout. Cette méthode ne crée strictement aucune erreur.
Pas de quiproquo STP,
Je me fiche totalement de savoir comment tu obtiens tes lignées ou comment tu fais tes calculs. Donc tes exercices, je m'en moque.
Je redonne l'image : je vois un type qui construit une tour verticale partant de Brest, et qui prétend qu'il arrivera à New York en allant toujours tout droit vers le ciel.
Tant que tu n'auras pas de ligne directrice cohérente, tant que tu ne sauras pas où tu veux aller, tu vas enchaîner des calculs et des tableaux... tous ridicules.
Non on ne fait pas la même chose. Je me moque des chemins. La structure de l'arbre est mon objet d'étude. Si je pouvez me passer à 100% des entiers je le ferai. Je veux arriver à ne travailler qu'avec les codes de lignées comme s'ils étaient des entités indépendantes des entiers. Il y a des règles qui peuvent parfaitement définir comme l'arbre se construit. Ce sont des règles de descendance ou de reproduction (cycle, fertilité, stérilité, etc..) qui n'ont rien d'exceptionnelles.
Je reviens là-dessus. Compter le nombre de termes pairs entre deux termes impairs revient au même, en plus compliqué, que de lire la valeur du terme correspondant de la séquence d'exposants. Par exemple, ..., 101, 152, 76, 38, 19, ... équivaut à ..., 3, ...
Si on appelle $t$ un terme de la séquence d'exposants, et $c$ un chiffre du code, on a
$c=\lceil t/2 \rceil$
On ne peut pas modifier la parité d'un exposant, et donc, remonter vers $n_0$ sur la base de son code oblige à s'assurer à chaque étape que $c$ respecte cette parité. Comme on n'a aucun moyen de le savoir, le test revient à remplacer $c$ par $2\,c$ puis par $2\,c-1$ dans $n_{i-1}=(n_i \times 2^c-1)/3$ afin de savoir lequel des deux donne un résultat entier. On s'impose donc une triple conversion : $t \to c$ puis $c \to 2\,c$ et $c \to 2\,c-1$. Quel individu normalement constitué agirait de la sorte alors qu'il peut utiliser $t$ directement
Je vais effectivement construire une tour à Brest. Elle suivra une trajectoire balistique jusqu'aux limites de l'espace et replongera en direction de New York où elle s'enracinera. En lui faisant faire une petite boucle à son apogée, des ascenseurs pourront circuler dans les deux sens sans que personne ne s'aperçoive de l'inversion. Ils auront l'impression de toujours aller dans le même sens comme dans un anneau de Moebius.
Maintenant que le problème architectural est réglé, je peux donc si tu le veux bien donner ma ligne directrice.
Ce n'est pas feu Paul Erdős qui dira le contraire : cette conjecture est-elle par essence un problème qui tourne en rond dans le logiciel mathématique ? Une sorte de boucle dont on ne peut sortir. C'est possible. En même temps, ce n'est jamais qu'un problème de générations et de descendances. Hors les maths, il y a une logique qui s'applique aussi. Donc l'idée est de démathétiser le problème en sortant des entiers. Construire un nouvel objet d'étude où on ne fait plus d'arithmétique. Mais évidemment il faut faire une correspondance solide avec la base de départ. Tu vas me dire que je tue le problème au lieu de le résoudre. Que ce transfert va ruiner la finesse du problème. Oui, mais on s'y noie dans cette finesse depuis des lustres. Alors....
Etape 1. De par les outils simples qui ont été décrits sur ce fil, un arbre peut se réduire à des objets ayant des relations entre eux. Je les appelle des codes de lignées mais on pourrait les nommer autrement. Le tout est de ne voir qu'un système qui se reproduit. Comme dans la nature, il y a un partage des tâches pour y arriver et surtout pas mal de contraintes. Ce système est aussi éternel et infini. Comme personne ne meurt, il grandit infiniment.
Etape 2. On oublie les pairs et les impairs, et tous ces chemins biscornus de montées et de descente. Il n'y a qu'une génèse d'objets à décrire. Un des premiers challenges est de construire une nouvelle orbite proprement en ne travaillant qu'avec les codes de lignées. Que se passe-t-il sur l'orbite précédente et comment va se construire la nouvelle? Qui apporte du sang neuf et qui ne le peut pas. Il y a des cycles, et des états de stérilité ou de fertilité. Donc un objet va suivre une histoire entre le moment où il apparait et celui où il devient la souche de toute une partie de l'arborescence. Dans ce système, l'adn est porté plus par le système que par les individus. Donc en fait tout est instantané même si la structure en orbites, assimilables à des générations. et donc qu'on pense un peu trop à une chronologie.
Etape 3. Imaginons que ce codage puisse fabriquer 1000 orbites, ou du moins décrire des morceaux d'orbites très lointaines. On va se demander si on aurait pu le faire avec l'algorithme. Et évidemment il faudra vérifier que ce qu'on fabrique dans un monde est toujours compatible avec l'autre. A terme on peut s'estimer satisfait et se dire que la structure de l'arbre est connue. Et tenter de décrire que certaines choses sont strictement impossibles (le fils est le père de son père semble impossible).
Tu bâtis un codage avec des lignées, des orbites et tout un tas de trucs. Eventuellement, en cours de recherche, tu vas inventer 3 ou 4 nouveaux mots pour décrire ce codage. Ou pour faire durer l'histoire.
Ce codage est basé sur le chemin qui part d'un entier quelconque et qui va jusqu'à 1.
Ce codage permet de coder tous les nombres qui aboutissent à 1 par l'algorithme de Syracuse.
On cherche à ne plus parler d'entiers ou de nombres ... donc on va dire de façon un peut différente : ce codage permet de coder tous les individus qui sont reliés à 1 par l'algorithme de Syracuse.
Donc pour tous ces individus là, tous ceux qu'on a su coder, tous ceux qui sont des descendants de 1, tu dis qu'on devrait pouvoir exhiber des résultats.
En particulier, on devrait pouvoir prouver que parmi tous les descendants de 1, on n'a aucune configuration du type "le fils est le père de son père"
Oui ... mais ça on le sait déjà : parmi les descendants de 1, il n'y a pas de cycle. C'est d'une banalité sans nom. Et même mieux, puisque tu veux démontrer des banalités : on sait déjà que parmi les descendants de 1, tous les nombres sont des descendants de 1.
Oui, c'est bien l'idée. Trouver le principe de construction, le squelette, l'organisation hiérarchique, etc... Donc isomorphe comme vous le dites, oui évidemment. X est le père de y qui est le père de z... On n'a pas besoin des entiers pour cette relation. Quand on parle de parents, d'enfants, de fratrie, non plus. Donc la première idée est de sortir l'organisation logique de l'arbre du contexte arithmétique en essayant bien sûr que les règles logiques soient compatibles.
Evidemment pour la question du "remplissage" c'est moins évident. On pourrait calculer éternellement pour montrer que ce remplissage fonctionne. Sauf qu'il faut calculer un arbre de millions voire milliards d'éléments pour avoir une suite remplie de 1 à 27 !
En tout cas, tout ce qui concerne ce "remplissage" est une des clés de cet arbre. On voit par exemple très vite le phénomène de "clusterisation" quand la population d'entiers présents dans l'arbre a tendance à se regrouper. Ce n'est pas aléatoire et très typique de Collatz.
1) Définir l'arbre de Collatz sans utiliser Collatz.
2) Définir les façons acceptables de remplir cet arbre (qui doit contenir Collatz).
3) Prouver qu'avec toutes les façons acceptables, l'arbre contient IN
J'affirme péremptoirement que toute affirmation péremptoire est fausse
Votre résumé est 3 points est correct
Je le précise donc en reprenant la même numérotation :
1) Dans le nouvel arbre que l'on peut appeler généalogique, un objet dit "code de lignée" remplace l'entier. Cet objet est un point de l'arborescence et ne contient rien d'autre que sa position dans l'arbre et l'information généalogique. La méthode de conversion d'un entier en code de lignée est un algorithme qui ne produit qu'un seul résultat. Il n'y a qu'un entier à une position donnée de l'arbre et donc un seul code de lignée. Arbre généalogique et arbre de Collatz sont homogènes.
2) La première façon de transformer un arbre de Collatz en arbre généalogique (ou arbre structurel) consiste à traduire tous les entiers impairs qu'il contient en codes de lignée. Cet arbre est donc à ce stade strictement semblable à son original mais totalement dépendant de l'algorithme de Collatz. Son intérêt est de servir d'objet d'étude pour définir les règles de construction indépendantes. Ces règles reposent sur un principe fondamental de reproduction. Le système est certes reproductible à l'infini mais il est régulé par des contraintes : cycle de reproduction et éléments stériles. N'importe quel code de lignée ne trouve donc pas sa place dans l'arbre. Quand ces règles sont acquises, un nouvel algorithme peut générer directement l'arbre. On peut considérer ici que la difficulté est surtout technique : trouver les bonne règles et les traduire correctement dans un code.
3) Quand le code de l'arbre généalogique est au point, on peut vérifier que la conversion des codes de lignée en entiers (l'algorithme est dispo) donne pour n orbites demandées un arbre de Collatz. Mais il faut savoir qu'un arbre d'une centaine d'orbite (nombre assez bas) contient déjà des milliards d'éléments. Les limites de calcul vont donc être vite atteintes. Pour des tests plus poussés, on peut générer un code de lignée correspondant à une orbite très grande et vérifier que l'entier correspondant est bien au bon endroit dans l'arbre de Collatz (notons ici que la conversion du code de lignée donne le chemin complet vers 2^n). Néanmoins ce seront toujours des vérifications par calcul. Mais je dis qu'à ce stade, les règles de l'arbre peuvent être étudiées c'est-à-dire que cette structure ne peut logiquement contenir que certaines formes d'arborescence et pas d'autres. Et la question sera : comment un entier peut-il ne pas appartenir à un arbre de Collatz puisque le propre d'un entier est d'être l'aboutissement d'une arborescence ? Si je disais que je peux créer un code de lignée sans arborescence, ce serait idiot puisque que ce code est un pur produit d'une arborescence. Il faut démontrer que c'est la même chose avec un entier.
Précision importante sur ma définition d'un arbre de Collatz.
Je me base sur une formulation alternative de la conjecture :
Soit i un impair et i' celui que l'on obtient après n itérations de l'algorithme tel que i' = i*3+1/2^n
En répétant ce processus, on arrive à un i' tel que i'*3+1= 2^n
Le plus petit 2^n de l'arbre est 2^4 associé à l'impair 5.
De ce fait le code de lignée de 5 est "1." (21 est "2." 85 est "3." etc...)
Les codes de lignée ne correspondent donc qu'à des impairs. Les pairs sont toujours de la forme i*2^n et i étant défini par un code de lignée il est inutile de les définir à leur tour.
1) Définir les "codes de lignées" sans allusion à Collatz et démontrer que Collatz n'est qu'un cas particulier.
2) "Trouver les bonnes règles" n'est pas une difficulté technique.
3) Il n'y a pas de problème de limite de calcul, puisqu'il faut démontrer pour tous les entiers (et pas seulement sur quelques-uns).
J'affirme péremptoirement que toute affirmation péremptoire est fausse