Bonsoir ,

c'est sûr, pour demain, à 20h55 ...
comme il est hors de question de te donner l'algo "tout fait" ça va être chaud.

la principale difficulté est purement technique : comment découper un nombre en deux, (c'est à dire obtenir le nombre formé par ses deux premiers chiffres, et le nombre formé par ses deux derniers chiffres)

les deux derniers chiffres, c'est le reste de la division de n par 100
on utilise l'opération qui s'appelle "modulo" ou "%" selon les logiciels
de toute façon il faut déja commencer par rédiger l'ago "en langage naturel"
"le reste de la division de n par 100" suffit, en langage naturel.

appelons r ce reste
le nombre formé des deux premiers chiffres c'est alors (n-r)/100

à toi de jouer :

pour n de 1000 à 9999 (c'est dans l'énoncé !)
découper, calculer, tester si etc afficher si oui.

Merci d'essayer de m'expliquer oui je sais il est tard mais malheureusement je me suis rendu compte il y a peu de temps que mon raisonnement de départ était faux donc pris de panique je demande de l'aide. J'utilise algobox.

n est une variable, pour n allant de 1000 a 9999 alors si n vaut le reste de la division de n par 100 + n moins ce reste divisé par 100 alors...

je t'avoue que je suis un peu perdu je n'avais même pas penser a utiliser "%"

n est une variable,
pour n allant de 1000 a 9999 OK jusque là
alors si

eh bien non
déja calcule proprement dans deux variables suplémentaires r = le reste de la division par 100
et dans p la valeur de (n-r)/100

et seulement maintenant que c'est propre, le test c'est dans l'énoncé :
est ce que r² + p² = n ou pas

vouloir écrire un algorithme "tout sur une seule ligne" est absurde :
- on n'y comprends rien
- c'est sujet à plein d'erreurs
- ça ne sert à rien

un algorithme doit être lisible, documenté et modifiable
(en le relisant deux ans après on peut comprendre ce qu'il fait, et comment il le fait)


ce n'est pas un challenge du genre "écrire le programme le plus tassé et le plus illisible possible, utilisant le moins de caractères possibles"
ça c'est pour jouer
pas pour faire de la programmation efficace.

n est une variable,
p est une variable
r est une variable
pour n allant de 1000 a 9999  
alors si r est le reste de la division n par 100 et p la valeur de la division de n moins ce reste par 100 alors
r prend la valeur r%100
p prend la valeur (n-r)/100
Fin Si
n prend la valeur p*p+r*r

Oui effectivement.

Bon et bien tant pis je ne l'aurai pas pour demain je m'y suis pris trop tard... merci quand meme

y a pas de "alors si"
c'est alors on calcule, toujours (pour chaque valeur de n), r = le reste de la division etc

puis une fois que c'est calculé pour cette valeur de n, seulement maintenant il y a le "si".
quand on rédige un algorithme et qu'on écrit "si" ça veut dire explicitement que l'on fait un test, une question "est-ce que ?"
pas du "si de décoration"
et pas du si qui contient des calculs de 10 lignes dans la condition du si elle même (qui en plus était fausse)

l'algorithme c'est exactement ce que tu ferais à la main :

pour chaque valeur de n je fais tout ça :
| je calcule directement toujours (y a pas de condition), pour cette valeur là de n,
| la valeur de r et de p
| puis je teste (je regarde si oui ou non) n est égal ou pas à r² + p²
| c'est là le "si"
| si oui j'ai une solution, je l'affiche
| ici, c'est "fin du si"
fin du pour, fin de la description de l'ensemble des opérations qui sont à effectuer pour chaque valeur de n
fin de l'algorithme (quand jai mouliné toutes les valeurs de n)

c'est ça qu'on fait, pas des "si" qui ne sont pas des si mais des calculs, et des calculs qui ne riment à rien du genre écraser la valeur de n par un truc qui n'a rien à voir. ou calculer un truc qu'on a déja calculé sans le dire etc ...