Pas de souci, chercher à répondre le plus justement aux spécification de l'excercice est effectivement la priorité n°1.
Ce qui n'enpêche pas de réflèchir transversallement et envisager d'autres solutions ou algorithmes alternatifs.
Même si en fin de compte on choisera celui qui répond et colle au mieux à l'excercice. L'avantage et que l'on le fait en connaissance de cause. Ce qui donne une avance certaine pour la suite :
- soit pour les excercice suivants qui seront certainemetn plus complexes,
- soit pour la suite, lorsque l'on retrouvera une problèmatique similaire, on se rappèlera des l'analyses effectuées, ce qui permettra peut-être de trouver une solution plus efficace ou inovante ...
Comme c'est un excercice, et que donc le travail produit sera évalué (par le prof.) il faut veiller cependant à bien respecter certains points essentiels :
- structurer à outrance son code : en effet c'est en excercice qui est là pour voir si l'on maitrise bien l'imbrication des boucles, si l'on sait structurer son programme;
Quand je corrige le TP de mes étudiant, je pars du principe qu'un code bien structuré indique une bonne analyse et un esprit clair qui a bien compris le problème.
- commenter à outrance : cela va de pair avec la structure du code. Ce qui est bien compris s'explique bien; ce qui est mal compris, négligé ou oublié ne donne lieu à aucune explication.
- ne pas chercher à optimiser : pour un excercice de ce type, c'est l'algorithme qu'il faut optimiser, pas le code. Donc, on fait des entrée-sortie claire et bien détaillée, les structure sont mise en évidence. On peut même utiliser des variables booléennes pour simplifier la compréhension des test, implication, imbrications ou sortie boucles
- nommer les procèdures, fonctions et variables de façon très explicite : privilégier les noms longs, rapellé dans le nom le type de donnée (nombre, chaine de caractère, booléen, ...)
Toujours tiliser des noms diffèrent pour des objets diffèrents, même s'ils contiennent ou produise la même information.
Par exemple, ne pas utiliser une variable qui porte le même nom qu'une fonction. Même si les interpréter actuels le permettent, c'est source de confusion et rend la lecture du code ambigüe si ce n'ait pas traitre. L'informatique a mis 150 ans à pouvoir manipuler des objets avec des noms indépendant du hardware ou de soft; il faut profiter de la liberté actuelle pour éviter les contrainte qui ont cassé les pieds aux pioniers.
- avoir un code qui fonctionne : notons que je mets cette contrainte en dernier, comme c'est un excercice d'apprentissage, il peut y avoir des cas où l'algorithme ou son implémentation souffre que quelque imperfaction.
Mais, si les points précèdents sont bien respectés, il sera facile de trouver l'erreur et de la corrigé.
Je ne pénalise les programme disfonctionnant que si le code est illisible, mal commenté, incompréhensible.
Comme tu opte pour la solution dichitomique et prennant à chaque étape la moitier de l'intervalle tu as deux solutions possibles pour la boucle principale :
- La boucle principale modifie (on dit maintient) l'intervalle de recherche en fonction des réponses de l'utilisateur; c'est ce que fait le code que tu as posté. Cependant, tel qu'il est (mal)structuré et organisé, on ne voit pas à sa lecture.
- La boucle principale parcours un arbre de recherche: c'est aussi une façon de faire, car les valeurs seront toujours les même puisque l'intervalle de départ est le même à chaque fois.
Dans ce cas, le code doit mettre en évidence cet arbre.
Dans tous les cas, le code doit être structuré, c'est à dire que l'on doit bien voir la pahse d'initialisation (ce qui est le cas), la boucle de recherche et la phase finale où l'on donne le nombre secret, le nombre de coups et l'éventuelle indication que l'on a pas trouvé.
Dans l'état actuel, la pahse finale est mélée à la boucle ce qui déstructure le code, l'alourdi et si c'était moi qui note ou le passe en revu occasionnerait une sanction.
Ce type d'excercice est souvent évalué sous trois aspect : Analyse - Structuration - Implémentation
Quand je fais un audit il y a en plus Documentation.
La clause de sortie de la boucle doit également être mise en évidence. S'il le faut ne pas hésiter à mettre un commentaire qui indique le mécanisme.
Tel qu'est fait le code actuel, on ne sort de la boucle de recherche que si l'on trouve. La réponse R==0 de l'utilisateur devient donc naturellement une bonne clause de sortie.
Il y a plusieurs façon de faire, quelque soit la solution utilisée, elle doit bien être expliquée et mise en évidence dans le code.
- Code: Tout sélectionner
with entrees_sorties;
use entrees_sorties;
procedure Devinette is
;-- Initialisation
v_Min :Integer:= 0; -- Valeur minimale intervalle de recherche
v_Max :Integer:=100; -- Valeur maximale intervalle de recherche
Dial :Integer;= 2; -- Réponse de l'utilisateur (-1,0,+1 et 2=initialisation)
nbre_Tentative:Integer:= 0; -- Compteur de tentative/propositions
nbre_Choisi :Integer:= (v_Max + v_Min)/2; --Nombre proposé par la machine
;-- Affichage règle du jeu
put("Pensez à un nombre entier entre ");put(v_Min);put(" et ");put(v_Max);putln(".");
;-- Boucle de recherche
begin
;-- Boucle tant que moins de 7 tentatives et réponse utilisateur differente de 0
;-- d'où l'importance de l'initialisation de Dial
While (nbre_Tentative /= 7) && (Dial /= 0) loop
nbre_Tentative := nbre_Tentative + 1;
put(nbre_Choisi); -- Affiche proposition
get(Dial); -- Obtient réponse utilisateur -1 moins, +1 plus 0 trouvé
nbre_Choisi := nbre_Choisi + Dial*(nbre_Choisi)/2;
End loop;
;-- Fin de programme - Affichages des résultats
if (Dial==0) then
put("Le nombre a été trouvé en "); putln(nbre_Tentative);
end if
if (nbre_Tentative>7) then
putln("Les 7 tentatives sont écoulées.");
end if;
end Devinette;
