Salut à tous blenderien, je sais que ce sujet n'a pas trop sa place sur un forum en rapport avec la 3d mais les autres forums sur lesquels j'ai posté et également des gens à qui j'ai demandé ne savent pas me répondre, et comme j'ai vu que sur le clan il y a des codeurs je me suis dit pourquoi pas !
Si personne ne sait me répondre pourriez vous me renvoyer vers des forums plus expert.
Bon alors voilà le problème pou m’entraîner au langage C j'ai décidé il n'y a pas longtemps de coder un programme de calcul de racine carré par dichotomie, vous allez me dire " hé mais ça sert à rien tu peux faire sqrt bla bla " Le truc c'est que c'est pour m’entraîner pas pour calculer des racines carrées, Le programme fonctionne a deux détail près:
1. La racine carré de 36 est 5.997799 donc il tombe presque juste mais pas totalement
2. Quand on demande une précision trop élevé le programme s'arrète
Voila le code

Citation :
je n'ai pas pris la peine de le commenter car je le trouve relativement simple, cependant si vous voulez des commentaires dites-le.
Merci d'avance.

edit;
: je ne suis pas sur d'avoir accès à Internet les jours qui vont suivre donc ne vous étonné pas si je ne répond pas .

Pour 1/, c'est normal : tu as un résultat approché qui converge vers le résultat réel. Donc, si tu n'itères pas assez, tu arrêtes le calcul avant d'avoir atteint une précision acceptable. Le calcul par dichotomie ne tombe jamais juste, sauf si par hasard tu as choisi des bornes qui tombent bien (avec 4 et 12, ça tomberait pile, par exemple).

Pour 2/, que veut dire "une précision trop élevée" ? Combien ? Et "le programme s'arrête" => comment ? Un message d'erreur quelconque ? Je ne vois pas ce qui peut faire planter un truc aussi simple...

Par ailleurs, le code peut se simplifier un chouilla en se passant de delta et m, qui n'apportent rien (ces variables ne servent que comme résultats intermédiaires, écrits et lus une seule fois) :

Bonjour Aspirine62400.
Je plussoie DaWaaaaghBabal le calcul de dichotomique ne peut pas tomber juste. Tu ne peux pas vraiment régler ton problème 1/ la seule chose que tu peux faire c'est vérifier si, par un coup de bol extraordinaire tu ne tomerait pas pile sur le bon nombre en rajoutant dans ton while quelque chose comme
Citation :
mais ça ne règle pas beaucoup de cas...

Pour 2/ après quelque tests je pense avoir compris le problème.Mon hypothèse est qu'il provient de la précision du format float en C. Quand tu demandes une trop grande précision ta variable eps vaut en fait 0 et ta boucle while devient infinie donc le programme s'arrête.

Solutions :
Tu peux partiellement régler ce problème en définissant tes variables en tant que long double ,qui est un type plus précis que float. Cependant, si tu demande une précision encore plus grande, tu auras le même problème.

En bref tu peux atténuer le problème mais pas le résoudre complètement à moins, peut être, d'utiliser une bibliothèque spécialisée dans le calcul en précision arbitraire de ce style (à vérifier je n'ai pas testé). Mais ça parait excessif vu la simplicité de ton programme.

Enfin si tu veux t'amuser tu peux essayer de coder la même chose avec d'autre algorithmes.Il me semble que la Méthode de Newton est bien plus rapide que la méthode dichotomique pour ce genre de calculs.

Voilà j'espère t'avoir un peu aidé (et ne pas avoir dis trop de bêtises)

Tout d'abord je vous remercie tous les deux pour vos réponses qui me sont très utiles, @ DaWaaaaghBabal et Vaydre, c'est bien ce que je craignais en effet, impossible de tomber juste avec le calcul par dichotomie, merci de me le confirmer, @ DaWaaaaghBabal, c'est vrai que j'aurai pu simplifier le code de cette façon, merci de me le faire remarquer, @ Vaydre, oui apparemment c'est ce qui se passe la boucle devient infinie, d'ailleurs sa en a tous les symptômes ! J'aurai du penser à utiliser un double mais comme tu le dis toi même ce n'est que repousser le problème, pour la bibliothèque ça devient un peu compliqué compte tenu de mon niveau mais c'est vrai que c'est intéressant, j'y reviendrai, quant à la méthode de Newton je ne la connaissait pas et merci de m'en avoir parlé, je vais m'y intéresser.
Encore merci à tous les deux quant a Vaydre je vois que c'est ton premier post donc bienvenue sur le
@+

Salut
C'est un problème d'algortihmique (numérique).

Comme dit, la dichotomie ne permet pas d'avoir un résultat précis dans certains cas mais c'est une méthode rapide. Pour les problèmes classiques il existe plusieurs méthodes et il faut choisir la meilleure selon ce qu'on recherche (performances vs résultat).
Ici, la méthode de Newton est efficace pour trouver une racine (carrée). Tu peux y jeter un oeil.

Il n'est pas utile d'utiliser les double parfois. La mémoire utilisée est doublée et il n'y a pas forcément de meilleurs résultats (l'expérience le montre). AMHA, GMP n'apporte rien dans ce cas, à part pour apprendre à s'en servir ce qui n'est pas inintéressant ! Si la méthode est foireuse, elle le reste. Ce n'est pas comme cela qu'il faut penser.

Ceci dit, pour le 2/ quand tu dis précision élevée, pense qu'un float, de par sa structure, ne peut aller au delà de 10-7 (il vaut mieux restreindre à 10-6 pour une meilleure précision). Donc si tu choisis quelque chose de plus petit il le considère comme étant 0 ou va savoir quoi...

Avant de lancer la boucle, fais donc un test sur la valeur rentrée par l'utilisateur... De toute façon, il faut toujours vérifier les données rentrées. C'est bien pour cela que l'interaction avec un utilisateur se fait uniquement à la fin du développement quand on est sûr que son moteur fonctionne sans bug.

Dans ce genre de programme, il faut généralement utiliser un garde fou (compteur et un nombre de tours max) qui permet de ne pas faire planter le programme en cas de forever. Tu conclues ton programme avec un test sur ce compteur : soit il est égal au nombre max et la racine n'est pas trouvée, sinon elle est approchée à la précision souhaitée.
Eventuellement l'utilisateur peut choisir le nombre d'iterations maximales (toujours en traitant cette donnée par la suite dans ton programme).

Ce que tu dit Bibi09 est également intéressant, je ne connaissais pas le principe du garde-fou et c'est intéressant, je vais également mettre un test sur la valeur en entrée, bonne idée.
Encore Merci de votre aide.