Problème mathématique pas évident... - Page 1

1- choisissez un nombre quelconque (disons 23, pour l'exemple)
2- calculez la somme des carrés des chiffres le composant (23 -> 2²+3²=4+9=13)
3- recommencez avec le résultat.

Voici la suite obtenue avec 2 : 2 -> 4 -> 16 -> 37 -> 58 -> 89 -> 145 -> 42 -> 20 -> 4
On se rend compte qu'on fini par tourner en rond quand on part de 2

Mais avec d'autres nombres, vous vous rendrez compte qu'au bout d'un moment :
- soit on se bloque (par exemple 7 -> 49 -> 97 -> 130 -> 10 -> 1 ... à 1 on ne peut plus rien obtenir d'autre que 1 indéfiniment )
- soit on atterrit dans la boucle de 2 (par exemple 3 -> 9 -> 81 -> 65 -> 61 -> 37) et donc on est sûr de tourner en rond.
- soit ??? Question 1 : en partant d'entiers entre 1 et 100, y-a-t il d'autres possibilités ? si oui, lesquelles ?

Question 2 : existe-t-il un entier quelconque à partir duquel la suite grandirait indéfiniment ?




Bon courage les gars
Notez que l'on peut répondre à la question 1 en codant un programme qui chercherait à notre place. Il n'y aurait pas beaucoup de mérite à le faire, car on peut y répondre mathématiquement, par contre on pourrait se faire un concours du programme le plus rapide.

le programme serait le plus interssant, de moi pt de vue

Bah allez-y, codez ! je vais le faire aussi
Mais si quelqu'un pouvait trouver une demonstration mathématique, ça m'intéresserait !

-

Thibaut a écrit :
Question 2 : existe-t-il un entier quelconque à partir duquel la suite grandirait indéfiniment ?

C'est celle-là la plus intéressante vu que pour la 1 il suffit de savoir programmer.
La réponse est non.

Le carré d'un chiffre est toujours <= 9² = 81, donc toujours un nombre de 2 chiffres.
En ajoutant n nombres de 2 chiffres, on obtient au maximum (n-1)*100+98. (Je n'ai pas envie de démontrer ça en détail. Ça doit pouvoir se faire par récurrence.)
Donc, on a au maximum un nombre de E(log(n-1))+3 chiffres (pour n>=2).
Donc en partant d'un nombre de n chiffres, et en effectuant la somme des carrés de ses chiffres, on obtiendra un nombre de E(log(n-1))+3 chiffres au maximum.
Il suffit de résoudre l'équation: n>log(n-1)+3(>=E(log(n-1))+3).
C'est vrai à partir de n=4. (Là aussi pas envie de le démontrer en détail.)
Donc un nombre de n>=4 chiffres sera toujours transformé en un nombre de moins de n chiffres, donc en un nombre plus petit.

Donc la suite ne peut pas diverger vers l'infini (mais elle peut diverger par oscillation évidemment, cf. l'exemple avec 2).

C'est vraiment impressionnant.
N'importe quel élève du niveau BAC S peut résoudre ça ou pas ?
Perso, en STI, on n'a pas trop vu les trucs genre log() ou E().
Sinon, t'as fait quoi d'autre comme études, Kévin ? T'es à la FAC, là non ?

jackiechan91 a écrit :

C'est vraiment impressionnant. N'importe quel élève du niveau BAC S peut résoudre ça ou pas ?

En théorie oui, en pratique non.

Perso, en STI, on n'a pas trop vu les trucs genre log() ou E().

C'est niveau TS.

Sinon, t'as fait quoi d'autre comme études, Kévin ? T'es à la FAC, là non ?

Oui. À son équivalent autrichien ("université (Universität)" par opposition à "école supérieure professionnelle (Fachhochschule)" - ce sont les 2 types importants d'université qu'il y a chez nous: la première doit ressembler à vos FACs, la deuxième à vos IUTs) pour être précis.

erf, mon dieu... et moi qui fait term S...
Je confirme : comme dit Kevin :

En pratique, non

La démonstration de Kevin n'est pas la plus simple. J'en ai trouvé une autre compréhensible par un élève de 6ème ce matin en prenant ma douche

J'ai programmé un petit executable pour répondre aux deux questions. Vous pouvez le télécharger ici :

Je défie PpHd de faire plus rapide (en C)

Tu peux expliquer ta demo, stp ?

-

C'est grâce à la supériorité de DevC++

Par contre, il a beau être super rapide, en le lançant ce matin à 2h00 sur mon Pentium 120 Mhz pour le faire chercher jusqu'à 2^32-1, il n'avait toujours pas terminé à 12h00. Mais le temps de recherche est inférieur à 5 minutes si on demande une recherche jusqu'à 40 millions

Pas le temps.

bo, il est pitet petit, mais c meme pas écrit ac les caractères OEM
bouhhhhhhhhhhhhhhhhhhhhh



bon, v regarder ça qd meme.

Espèce de moule ! avec DJGPP ça donnerait la même chose (en codant avec un éditreur Zindow$)

Alors tu as une démonstration à proposer, ou un programme plus rapide ?

g jamais dit le contraire. fallait bien que je critique
(quoiqu'il suffit d'utiliser ultraEdit )

>demo
je prefere plûtot avancer ******

Y'a que Kevin qui a réussit à répondre alors ?

-

c un *** ** **.

-

HAAAAAAAA SATAN !!!! édite-nous ce post !!!!

> jackiechan91:

C'est facile, pour en entier n donné, quand tu fais E(ln(n)/ln(b))+1, tu obtiens le nombre de chiffres de la représentation en base b du nombre n (E désignant la fonction partie entière).

Dans le cas de Kevin, comme log(x) = ln(x)/ln(10) pour tout x de R+*, alors E(log(n))+1te donne le nombre de chiffres de l'écriturez décimale de n.

+1, mon cher. +1

EEEuuuuuhhhhh oui très cher

J'édite

Pas besoin de compiliquer le probleme...
Soit u la suite qui associe a un nombre la somme des carrés de ces chiffres...
u0 peut prendre la valeur 1 ... 100
or u1 max => u0=99 c'ad u1=2*9²=162

pour tout u0 != 99, u1<162

maintenant...
n peut etre decomposé: x*100+y*10+z
or on a pour tout z: z²<=(z-1)²+81
donc le nombre max de u2 sera le nombre tel que u1 = 159 et u2 appartient a l'ensemble majore par la valeur 1+25+81=107
de meme on prend le nombre max qui sera 99 (ho miracle....) donc la suite est majoré par 162 et minoré par 0.

top dur pour moi tout ça !

-

seconde je veux bien mais petit j'en suis pas si sûr

TiMad
a écrit : u0 peut prendre la valeur 1 ... 100

Mais on veut la démonstration pour un nombre quelconque (pas nécessairement entre 1 et 100)! C'est ce que je démontre dans le message #5.