Dans ce cas il faut commencer par des exemples pour comprendre.
Au fait, vérifie ta définition :  Un+1 = S(Un)n = S(Un)*n ?   ou Un+1 = S(Un ?

Exemples (en supposant Un+1 = S(Un)) :

U0 = 1
U1 = S(1) = 1² = 1 = U0  STOP

U0 = 2
U1 = S(2) = 2² = 4
U2 = S(4) = 4² = 16
U3 = S(16) = 1²+6² = 37
U4 = S(37) = 3²+7² = 58
...
Etc jusqu'à trouver un Un égal à l'un des Uk déjà calculés avant.

Merci de ton aide. Maintenant j'ai compris mais pour l'exmple que tu a donnée, on retrouvera jamais un des termes déjà calculé

U0 = 2
U1 = S(2) = 2² = 4
U2 = S(4) = 4² = 16
U3 = S(16) = 1²+6² = 37
U4 = S(37) = 3²+7² = 58
U5 = S(58) = 5²+8² = 89
U6 = S(89) = 8²+9² = 145
U7 = S(145) = 1² + 4² + 5² = 42
U8 = S(42) = 4² + 2² = 20
U9 = S(20) = 2² + 0² = 4 STOP
C sa?

Oui, c'est exactement ça .

Donc tu vas devoir :
Gérer un compteur N et la liste U(N) des valeurs successives de U.
Faire une fonction S(X) qui calcule la somme des carrés des chiffres de X.
Initialiser N=0 et U(0)=Saisie
Faire une boucle principale qui incrémente N, dans laquelle tu calcules S(U(N-1)) que tu stockes dans U(N) , et surtout, tu lances une boucle secondaire, sur I vaiant de 0 à N-1 (après incrément de N), qui vérifie si U(N) n'est pas égal à une des valeurs de U(I).
Si c'est le cas, tu affectes la valeur "STOP" à une variable CONDITION, initialisée à "CONTINUE" avant la boucle, et placée comme condition d'arrêt dans la boucle principale :  TANT QUE CONDITION = "CONTINUE" : N=N+1, ...

Tu affiches les résultats à la fin : valeur de N, quel U(I) = U(N)...
En option, tu peux tracer les valeurs successives de U(I) et leur décomposition en sommes de carrés de chiffres pour faire joli et surtout pour vérifier le calcul.

Selon ta préférence, tu peux choisir d'incrémenter N au début ou à la fin de la boucle principale.
Il faudra juste bien faire attention à choisir la bonne valeur de N selon ton choix.

Bon courage .

Bonjour ou plutôt vu l'heure bonsoir.
La première chose que je me suis posée est : Le problème posé a-t-il une toujours une solution et peut-on donner une majoration du nombre d'itérations à faire? J'entend par solution du problème pour U0 donné les 2 indices i et j pour lesquels Ui=Uj. Si on ne sait pas si le problème posé a une solution ou pas , on risque d'entrer dans une boucle sans fin si le problème posé n'admet pas de solutions. Est-il raisonnable de dérouler l'algorithme dans le cas contraire, (le nombre d'itérations à faire peut être astronomique.)  
Je suis en train de chercher
i)  si le problème a toujours une solution (j'ai une idée en cours).
ii) trouver si possible une majoration du nombre d'itérations à faire...

Je pense qu'il y a toujours une solution au problème

SI tu as un algo a proposer, fait le voir car moi j'ai aucune idée

Bonjour.
Soient U un entier et V un entier obtenu de U en lui ajoutant des zéros à droite ou lui intercalant des zéros entre ses chiffres il est évident que S(U)=S(V),même chose si V s'obtient par permutation des chiffres de U, le nombre maximal d'itérations est C100 où maintenant C est le nombre de chiffres non nuls de U0. Cette remarque pourra peut être améliorer l'algorithme surtout si l'on veut établir un tableau des solutions pour 2U0m car il est plus rapide de chercher si le problème a été déjà résolu que de relancer les calculs mais c'est peut être hors sujet.

Bonjour delta-B.

J'avais déjà expliqué il y a une semaine la majoration du nombre d'itérations par 100*C, et donc la convergence assurée de l'algorithme, dans un nombre d'itérations raisonnable.

En pratique, l'algorithme est très simple et converge en quelques dizaines d'itérations quelle que soit la valeur de départ, puisque dès la deuxième itération, on est déjà forcément ramené à une valeur à trois chiffres... laquelle converge rapidement.

Bonjour LeDino

Merci pour l'algorithme.
Juste que ma remarque peut servir à accélérer dans certains cas le calcul de la somme des chiffres de U0 c'est quand celui-c contient par exemple le chiffre 0. On pourra chercher d'autres conditions pour optimiser le calcul de la somme des chiffres de U0. Laissons ça pour un maniaque de l'optimisation des algorithmes.(Apparemment j'en suis un.)  

Chacun ses passions .

Mais bon là il n'y a pas vraiment matière à optimiser.
Les suites convergent en une vingtaine d'itérations en moyenne.

Bonjour
  Et vous avez bien raison, l'élimination des zéros nécessite elle-même un autre algorithme.

Oui si on veut : 0 fois 0 égale la tête à toto .
Donc pas besoin de s'en occuper, la somme des carrés avale les zéros comme PacMan avale les rangées d'ananas ...

Bonjour LeDino.

J'aimerai bien savoir que va donner votre algorithme (et non pas vous) pour U0 = 10¹⁰⁰ avec n=2¹⁰⁰. Tous les deux on sa1t que U2=U1. J'aimerai bien attendre votre réponse mais je ne le pourrai pas et ceci sans mauvaise volonté de ma part.

Re-Bonjour LeDino.

Quand j'ai 'que va donner algorithme' je parlai de son exécution sur machine. L'algorithme lui toujours calcule toujours le carré du chiffre qu'il soit égal à zéro ou pas.

Bonjour,

U0 < 10¹⁰⁰   donc compte au plus 100 chiffres.
U1 < 100*100    ... donc compte au plus 4 chiffres.
U2 < 4*100      ... donc compte au plus 3 chiffres
... de même que tous les Un suivants, tous inférieurs à 300.

Donc en partant de U0 ~ 10¹⁰⁰ on aura à peine quelques itérations de plus qu'en partant simplement de U0 = 999.

Il en serait de même en partant de U0 < 10ⁿ avec n=10¹⁰⁰ :
U0 aurait au plus 10¹⁰⁰ chiffres et on retrouve le cas précédent en une seule itération !

Même en partant d'un nombre gigantesque, quelques itérations nous ramènent à un nombre à 3 chiffres qui converge en moins de 300 cycles (une trentaine au plus dans la plupart des cas).

Pour ce qui est de la programmation de l'algorithme, c'est une autre histoire si on veut partir d'un U0 plus grand que 10¹⁵ : il faudra stocker les nombres dans une liste, car les langages de programmation courants ne prennent pas en compte des nombres si grands.

J'espère que ça répond à tes questions...

Bonjour Ledino

Quand je voulais éliminer les chiffres zéro de U0, je pensais a la boucle qui calculait S(UO) et à sa programmation sur machines mais j'ai remplacé un problème par un autre qui ne fait qu'augmenter le temps d'exécution voir même plus que le doubler (si le nombre donné ne contient pas de chiffres zéro).
Je vais encore vous embêter: Eliminer chaque paire des chiffres 3 et 4  par le chiffre 5 puisqu'on a 3² + 4² = 5²

Tu ne membêtes pas du tout ...
Mais je ne vois pas pourquoi tu t'obstines à vouloir opimiser un algorithme qui tourne très bien tel qu'il est...
De surcroît, chacune de tes "idées" est plus coûteuse à appliquer que de faire simplement la somme des carrés des chiffres.

Et rappelle-toi que même pour un nombre gigantesque au départ, on se ramène très vite à quelques chiffres (en trois itérations maximum...).

Optimiser "oui". Mais à condition de gagner du temps .

Bonjour Ledino.

Je ne cherche plus à optimiser l'algorithme (- quand même je ne suis pas bête à ce point -) puisque l'élimination des zéros (et le remplacement de la paire 3,4 par 5) ne fait qu'augmenter le temps machine (voire le doubler) comme je l'avais dit. Je vous ai taquiné dans mon précédent message et je vous ai bien embêté puisque vous y avez répondu.
Bonne journée.  

Ah c'était juste une blague ?
Je vais t'avouer un truc : après l'enchainement de tes messages... ça me rassure .

Cela dit, je ne voudrais te décourager de vouloir en général optimiser les algorithmes que tu conçois.
C'est un excellent réflexe à développer le plus tôt possible.
Après, il faut juste trouver le bon équilibre ...

salut


en fouillant dans mes favoris j'ai retrouvé ce topic ... que je me permets de compléter ... (et pour l'avoir dans mes messages) ...

on ne s'intéresse qu'aux nombres < 300 .... puisqu'on s'y ramène en quelques étapes ....


  et  


on veut donc résoudre l'équation

où a, b, c, x, y et z sont des chiffres

et il existe une suite conduisant de u_i à u_j


si on considère la fonction définie sur le cube {0, 1, ..., 8, 9}³ alors f est invariante par permutation


on a le théorème de Gauss :: n est somme de trois carrés si et seulement si n 4a(8b - 1)
ça en fait donc pas très beaucoup ....

voir


enfin voila quelques éléments ....


to be continued ...