Une boucle infinie : j'ignore pourquoi

Code:

---

1 2 3 4 5 6 7

for (int chiffre = 0; chiffre <= 9; chiffre ++) { k = 0; while (tabPosition[chiffre][k] != -1) { nb += chiffre * pow(10,tabPosition[chiffre][k]); k += 1; } }

---

(je remets le bout de code sans mon cout d'espionnage)
mais l'incrémentation de k s'arrête bien dès que tabPosition[chiffre][k] = -1 non ? ensuite, on passe au chiffre suivant.

Citation:

---

mais l'incrémentation de k s'arrête bien dès que tabPosition[chiffre][k] = -1 non ? ensuite, on passe au chiffre suivant.

---

Et ? En quoi faire exactement la même chose avec un for aurait un résutlat différent ?

Ce code est de toutes façons mauvais puisque tu débordes de tabPosition. Et potentiellement sur 2 dimensions.
Un tableau de 9 cases ça s'itère sur [0, 9[

Les bases sont à (re)voir.
Utiliser for aurait au moins le mérite de mettre en avant que tu débordes également sur k.
Sinon il y a tout simplement la ranged-for-loop.

si c'est pareil....y a vraiment un truc qui m'échappe.

Le tableau à la base c'est ça :

Code:

---

int tabPosition[10][9]

---

Si j'imbrique 2 boucles for, alors je vais parcourir les ... 90 cases.

Alors qu'avec la boucle while dans la boucle for, puisque l'incrémentation s'arrête dès qu'il n'y a plus de nombre qui m'intéresse, je ne parcours pas tout le tableau, et même beaucoup moins.

Maintenant il est fort probable que l'économie ne vaut pas la peine de prendre le risque d'une boucle while, ça je ne le nie pas.

for, tout comme while, prend une condition que tu es libre d'écrire comme bon te semble. :calim2:

Code:

---

1 2 3 4 5

k = 0; while (tabPosition[chiffre][k] != -1) { nb += chiffre * pow(10,tabPosition[chiffre][k]); k += 1; }

---

est absolument identique à

Code:

---

1 2	for (unsigned k = 0; tabPosition[chiffre][k] != -1; ++k) nb += chiffre * pow(10,tabPosition[chiffre][k]);

---

Tu ne parcours pas plus, n'utilises pas plus de CPU ni n'importe quelle autre mauvaise raison invoquée. :weird:

Par contre ça ne change pas le fait que k ne soit pas borné, et donc tu risques une super boucle quasi infinie jusqu'à ce qu'un -1 se retrouve par hasard en mémoire.
Et vu que juste avant tu initialises chaque valeur à son index de position... le cas peut se produire avec certaines valeurs élevées.
Pour ça il faudrait au moins

Code:

---

1 2	for (unsigned k = 0; k < 8 && tabPosition[chiffre][k] != -1; ++k) nb += chiffre * pow(10,tabPosition[chiffre][k]);

---

Ou en utilisant un ranged-for-loop (disponible depuis bientôt 9 ans), que je trouve bof dans ce cas

Code:

---

1 2 3 4 5 6

for (int k : tabPosition[chiffre]) { if (k == -1) break; nb += chiffre * pow(10,k); }

---

Et dans tous les cas l'utilisation d'un std::vector ou std::array devrait être le B.A.BA.

En effet je ne savais pas qu'on pouvait faire ça avec une boucle for ! Enfin maintenant que je le vois, ça paraît assez évident....
J'ignore pourquoi ma prof d'algo/progra n'utilise pas ça.....dans ce genre de cas, quand elle ne veut pas parcourir tout le tableau, elle utilise toujours une boucle while.

Pour les autres bibliothèques...on est pas censé les utiliser...l'objectif je suppose est de rester le plus proche possible de l'algo, sans se faciliter la vie avec les possibilités qu'offrent les différentes bibliothèques.

Merci infiniment d'avoir pris le temps de m'expliquer Bousk :zoubi:

Citation:

---

Envoyé par RowanMayfair

dans ce genre de cas, quand elle ne veut pas parcourir tout le tableau, elle utilise toujours une boucle while.

---

Et elle a raison :mrgreen:

Parce qu'avec une boucle pour c'est exactement N itérations alors qu'avec une boucle tant que c'est au plus N itérations avec au minimum 0 (et une boucle faire ... tant que c'est minimum 1 itération)

Mais en C, la syntaxe de la boucle pour est assez permissive :mrgreen:

oulà...en voilà des subtilités :mouarf:

Donc si je résume, en C++ je peux "bidouiller" une boucle for pour qu'elle ne parcours pas tout le tableau, mais s'arrête lorsque ma condition n'est plus remplie
....et dans les autres langages la boucle for reste le brave bourrin que j'imaginais et parcours tout le tableau, il faut donc utiliser une boucle while si je veux pouvoir la stopper

Oui, mais non, ces "subtilités" existent dans quasiment dans tous les langages que je connais, et ils sont assez nombreux, et c'est plutôt les langages fonctionnels qui font exception.

On choisit plutôt une forme de boucle plutôt qu'une autre en fonction de la lisibilité du code qui en résulte.

Il n'est pas rare de passer d'une forme de boucle à une autre en fonction de l'évolution des conditions de sorties plus ou moins complexes.

On ne peut pas trop critiquer ton prof. qui t'inculque les bases de l'algorithmie.

Mais il ne faut pas trop calqué les principes d’algorithmie avec les formes syntaxique d'un langage qui s'en inspire. (Être souple sur ses appuis ;) )

Citation:

---

Envoyé par foetus

Et elle a raison :mrgreen:

Parce qu'avec une boucle pour c'est exactement N itérations alors qu'avec une boucle tant que c'est au plus N itérations avec au minimum 0 (et une boucle faire ... tant que c'est minimum 1 itération)

Mais en C, la syntaxe de la boucle pour est assez permissive :mrgreen:

---

Ton message, si ce n'est erroné, peut prêter à confusion ! À toi le soin de te reprendre.

Citation:

---

Envoyé par RowanMayfair

Possible que dans ce bout de code la boucle while fasse la même chose qu'une boucle for....sauf qu'on nous apprend à optimiser au maximum nos algorithmes, or dans ce cas la boucle while permet d'arrêter le parcours à la 1ère valeur -1, au lieu de parcourir tout le tableau. Petite économie en terme de temps d'exécution machine.

---

Là on est typiquement de le cas d'une tentative d'optimisation prématurée ("premature optimization is the root of all evil"; Donald Knuth)
On ne fait pas ça en programmation, surtout si ça a pour conséquence de nuire à la lisibilité du code.
En C++, c'est le compilateur, extrêmement puissant, qui se charge de ce genre d'optimisations.
Après, s'il y a vraiment quelque chose à optimiser, c'est avant tout dans le design de l’algorithme qu'il faut le faire.

La question c'est comment exprimerais-tu, avec des mots, cette partie de ton algorithme ?
Ton deuxième principe de programmation: "Ce que l’on conçoit bien s’énonce clairement, Et les mots pour le dire arrivent aisément" (Nicolas Boileau).
Ta réponse à cette question te dira si tu dois utiliser une boucle for ou une boucle while.

clairement moi j'aurai utilisé une boucle for, sans hésitation.
Je ne suis déjà pas très à l'aise quand je manipule des boucles imbriquées (en tout cas pas aussi à l'aise que je le voudrai), donc en plus se torturer avec une boucle while pour économiser un si petit bout de parcours, ça ne m'aurait pas effleurée.

Maintenant, la correction proposée est sans doute pour nous sensibiliser (nous, étudiants incultes) à l'optimisation. Et puis c'est peut-être devenu une habitude de codage.
J'ai l'impression que les développeurs finissent par développer ... ce qu'on pourrait appeler des tics parfois :mrgreen:

Bonjour,

RowanMayfair, la clé pour y arriver est de bien décomposer le problème en sous-problèmes.
As-tu vu les fonctions dans ton cours ? Si oui, alors c'est le moment parfait pour les utiliser pour décomposer le code.
Par exemple, la première décomposition à faire est de séparer d'une part le fait que le programme continue tant qu'on ne saisie pas 0, et le fait de décomposer le nombre en chiffres avant de le reconstituer :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <iostream>   void afficherLesPoidsDesChiffresPuisLeNombre(unsigned long int nb);   int main() { bool continuer = true; while(continuer) { unsigned long int nb; std::cout << "Entrer un nombre entier de 9 chiffre maxi = "; std::cin >> nb; if(nb == 0) continuer = false; else afficherLesPoidsDesChiffresPuisLeNombre(nb); } return 0; }   void afficherLesPoidsDesChiffresDe(unsigned long int nb) { std::cout << "Le code actuel ne fait rien pour l'instant.\n"; // code à changer }

---

Si tu n'as pas vu les fonctions, tant pis, mais décompose au moins le code dans ta tête :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <iostream>   int main() { bool continuer = true; while(continuer) { unsigned long int nb; std::cout << "Entrer un nombre entier de 9 chiffre maxi = "; std::cin >> nb; if(nb == 0) { continuer = false; } else { std::cout << "Le code actuel ne fait rien pour l'instant.\n"; // code à changer } } return 0; }

---

L'idée, c'est que, quand on s'occupe du code qui gère le fait que le programme continue tant qu'on ne saisie pas 0, on ne fait attention qu'à une petite partie du code du programme : on n'a pas besoin de faire attention au code qui s'occupe de décomposer le nombre en chiffres avant de le reconstituer.
De même, quand on s'occupe du code qui décompose le nombre en chiffres avant de le reconstituer, on peut oublier la grande boucle qui gère le fait que le programme continue tant qu'on ne saisie pas 0.

Il n'y a pas besoin de faire entrer tout l'algo en même temps dans sa tête.

De même, le code qui décompose le nombre en chiffres avant de le reconstituer peut être décomposé en 4 étapes :

1. Décompose un nombre en chiffres, par exemple décomposer 7377683 en un tableau qui contient, dans l'ordre, 3, 8, 6, 7, 7, 3 et 7.
2. À partir d'un tableau de chiffres, par exemple qui contient 3, 8, 6, 7, 7, 3 et 7, créer et compléter le tableau à deux dimensions imposé par l'exercice.
3. À partir du tableau à deux dimensions imposé par l'exercice, afficher les poids non nuls des chiffres.
4. À partir du tableau à deux dimensions imposé par l'exercice, reconstituer le nombre et l'afficher.

Bon courage.

Je sais ce qu'est une fonction pour les utiliser en programmation, mais en effet à ce stade pas en algo. Enfin on était pas censés en utiliser.

J'ai fini par comprendre cet algo. Ce qui m'ennuie, c'est que je ne suis pas certaine, face à un problème similaire, d'être capable de le refaire seule.
Et ça me ... frustre....parce qu'en vrai, j'aime ça l'algo, même si je ne suis pas très douée :lol:

Rome ne s'est pas faite en 1 jour, et personne ne nait avec un clavier dans les mains (enfin, pas encore). ;)