Discussion :

[tbc92]

La fonction donne la bonne réponse, mais c'est un coup de chance.
Une fonction doit être 'cohérente', et autonome.

Lance ton programme, avec l'instruction moitie(35000000) ;
Ca va te dire au bout de combien temps on divise le nombre de bactéries de moitié, si au début il y a 35000000 bactéries.
Normalement.
C'est à ça que sert une fonction.
Est-ce que le résultat te semble correct ?

Si on commence avec 10 bactéries, au bout d'une seconde, on aura 9 bactéries (et pas 9.8) ; au bout de 2 secondes, on aura 8 bactéries, ... et au bout de 5 secondes on aura 5 bactéries.
Donc avec 10 bactéries au départ, on tombe à la moitié au bout de 5 secondes seulement.
La formule avec des log() est valable pour des très grands nombres, mais pas pour des petits.

[Sve@r]

Pour le 500 000, je me suis basé sur ce que disait la fin de l'énoncé qui disait moitié de la population initiale,

Justement, la fonction doit donner la bonne réponse quelle que soit cette population. Si on lui passe 150 bactéries, elle doit trouver au bout de combien de temps ça passe à 75, pas à 500000 (cf mon exemple).

quant à la fonction bacteries, c'est la solution qui a été donnée en correction à l'époque et elle n'émanait pas de moi
par conséquent, étant donné que c'était la solution de correction, je n'ai pas creusé plus loin de mon côté, mais avec
le recul, j'me dis que j'aurais peut-être dû.

Oui. Même si la solution n'est pas de toi, tu dois t'en servir pour la suite de l'exercice

La fonction donne la bonne réponse, mais c'est un coup de chance.

En réalité même pas, elle donne 36 alors que la bonne réponse est 35. Faute à l'incrément de n qui se fait une fois de trop.

[DeltaFrost145]

Bon bah, maintenant je le saurais pour la suite, si ça me paraît trop facile, c'est que ce n'est pas la bonne réponse,
le prochain exo est encore plus compliqué, là je vais vraiment transpirer pour trouver la solution,
en tout cas, merci pour votre aide et votre temps, je vous souhaite une excellente journée .

[Sve@r]

si ça me paraît trop facile, c'est que ce n'est pas la bonne réponse,

Absolument pas !!! Ce n'est absolument pas ce qui a été dit ici !!!
Si tu regardes mon code, la première fonction fait une ligne et la seconde en fait trois. Tester n=1 seconde, n=2 secondes, n=3 secondes et etc jusqu'à trouver n tel que bacterie(N, n) devienne inférieur à N/2 c'est pas super complexe comme fonction (je ne veux pas employer l'adjectif "facile" mais franchement il y a de quoi !!!)
Ce qu'il te faut c'est éviter de mettre du code au hasard. Si on te dit "cette fonction reçoit un truc" alors ce n'est pas pour écrire def fct(trucA, trucB) sans savoir ce que représente "trucA" ou "trucB" ni surtout pourquoi en mettre deux alors qu'elle ne doit en recevoir qu'un seul. Ton tout premier code montrait que tu avais quelque part saisi l'idée mais si on te demande "une" recherche alors il ne faut pas écrire "deux" boucles. Si je te place 15 bouteilles et que je te demande laquelle contient de la bière, tu vas les examiner une à une et faire un seul tour, pas 225.
Accessoirement utiliser "n" et "N" pour deux entités différentes n'aide pas non plus à bien conceptualiser les choses. Toutefois là ce n'est pas non plus entièrement de ta faute (le créateur de l'énoncé aurait pu y penser de lui-même)

[DeltaFrost145]

Ah, on est bien d'accord, j'osais pas le dire pour éviter de me prendre une prune facile mais déjà je trouve que l'énoncé est UN PETIT PEU vague, mais en attendant, tu as dit dans un tes messages précédents que ce n'était pas au niveau de la programmation que je devais faire un travail mais au niveau de la rigueur et je ne sais plus quoi, tu aurais des conseils pour m'aider à m'améliorer ?

[Sve@r]

tu aurais des conseils pour m'aider à m'améliorer ?

Ne pas passer à la partie 2 tant que tu n'as pas terminé (et testé) la partie 1. Quand tu as des soucis de résultat tu rajoutes des print() avant et après pour vérifier si les valeurs reçues et renvoyées correspondent. Ne pas démarrer une fonction en écrivant def fct(xxx, yyy) sans savoir au minimum ce que représentent "xxx" et "yyy" pour toi et pour la fonction. Ne pas écrire for n in range(...) sans savoir ce que ça implique ce qui évite ensuite d'écrire n+=1. Ne pas boucler sur "tant que V aura/n'aura pas telle valeur" sans modifier ensuite quelque part dans la boucle ladite valeur "V".
Le reste vient avec l'habitude

[DeltaFrost145]

J'en prends bonne note, merci pour ton retour, j'ai une dernière question, à l'époque où j'ai fait la remise à niveau, le prof nous a mis directement dans le bain avec la programmation mais nous n'avions aucune notion d'algorithmique mes camarades et moi, est-il essentiel d'avoir des notions d'algorithmique AVANT de passer à la programmation (d'où le cahier d'exercices et dans ce cas-là, c'est le prof qui n'a pas fait son travail correctement) ou bien est-il possible "d'apprendre sur le tas" au risque de s'en tirer TRÈS souvent les cheveux ?

[Sve@r]

L'algorithmique au sens propre c'est la formalisation d'une solution dans un langage fictif ressemblant aux langages réels. Ce langage aura des instructions comme "TANT QUE FAIRE ... FIN FAIRE" ou "SI ALORS SINON FIN SI".
Cela permet de former son cerveau à la résolution de problèmes informatiques sans avoir vraiment de langage pour ça (ni même d'ordinateur, on fait alors tout sur papier).

Si tu as déjà un ordi et un langage de disponible, ça devient alors inutile d'en apprendre un autre "imaginaire" alors que tu en as un de réel à ta disposition. L'algorithmique c'est un peu comme les roulettes de stabilisation d'un vélo. Ca peut servir un peu au début mais faut apprendre à s'en passer vite.

Ensuite ce qu'il faut faire, c'est connaitre le comportement des instructions de contrôle if/while/for surtout que ce sont des instructions qu'on retrouve dans quasiment tous les langages (au-moins dans tous les langages sérieux et non les langages tels que "brainfuck" faits pour amuser les nerds)

[DeltaFrost145]

D'accord, donc en fin de compte, il n'y a qu'en pratiquant régulièrement et en prenant les problèmes avec une bonne dose de recul que je serais en mesure d'aller loin et d'être plus rapide sur la résolution de problèmes, si j'ai bien compris

[wiztricks]

nous n'avions aucune notion d'algorithmique mes camarades et moi, est-il essentiel d'avoir des notions d'algorithmique AVANT de passer à la programmation (d'où le cahier d'exercices et dans ce cas-là, c'est le prof qui n'a pas fait son travail correctement) ou bien est-il possible "d'apprendre sur le tas" au risque de s'en tirer TRÈS souvent les cheveux ?

La programmation est un apprentissage de l'algorithmique. Ouvrez un tuto qui propose des exercices corrigés et essayez de faire les exos sans regarder la solution. Cela va vous familiariser avec les messages d'erreurs et à la relecture critique de ce que vous avez écrit: c'est un bon apprentissage de la rigueur!

Comment tester que ce que vous avez codé fonctionne tel qu'attendu fait partie du boulot... Car ça oblige à réfléchir a ce que le code doit faire et à imaginer les différentes étapes à suivre dans le traitement pour obtenir le résultat. De plus impossible de coder sans avoir une idée de ce à quoi le code devra ressembler.

Puis à ce moment là, vous pouvez comparer ce que vous avez fait avec le corriger et s'ils sont différents, essayer de comprendre pourquoi sera très instructif.

La programmation ne se réduit pas aux algorithmes ou à l'écriture du code.
C'est partir d'un besoin exprimé en français et le retraduire/reformuler une ou plusieurs fois de façon à ce qu'on puisse construire une solution.
Et on s'assure à chaque étape de reformulation de retrouver l'expression du besoin de départ.

Une solution étant l'assemblage de petits bouts, comment découper le problème en morceaux histoire de pouvoir les fabriquer indépendamment les uns des autres puis arriver à les assembler sans trop de déconvenues? C'est çà "programmer": fabriquer un plan de construction de la solution qui pourra nous guider pour réaliser pas à pas, de façon sure.

Dit autrement, écrire 10 lignes de code, c'est pas pareil qu'en écrire 1.000 ou 100.000: il faudra d'autres savoir faire qui entrent aussi dans ce qu'on appelle "programmer".


- W

[DeltaFrost145]

J'ai compris, merci à vous Wiztricks