Programmation d'une somme infinie

[Sylviel]

Fait sur C++ :http://codepad.org/oIKR1Nin

A force de diviser par deux un nombre float ou double on arrive bien à 0 exactement.

En revanche c'est vrai qu'en pratique numérique on ne teste pas d'égalité entre des nombres floattants car il y a trop d'imprécisions numériques "machine". Les langages scientifiques (matlab par exemple) sont la plupart du temps protégé contre cela en ayant un epsilon défini par défaut bien supérieur à la précision machine. Et ce n'est pas la première fois qu'on en parle.

Si on fait tout soit même il faut bien sûr vérifier que la valeur absolue de la différence est petite et non l'égalité entre les deux flottants.

P.S : et un code alternatif au cas tu n'aimes pas "!="
http://codepad.org/PnQtNRgV

P.P.S : sur excel (google docs) j'ai fait ton test : je pars de 1, je divise par 1 000 000 de manière répétées. Au bout de 50 ligne l'égalité avec 0 (une case = 0. et non pas l'affichage bien sûr) est vérifiée.

[chan79]

:L'algo utilise le fait que, si on doit calculer TOUT les pour n de 0 à N, le plus rapide est de les calculer par récurrence : et pour

salut
c'est pas ?
Je suppose qu'il y a un oubli des parenthèses autour de 4n dans l'énoncé initial.

[Ben314]

c'est pas ?

si, effectivement...

Je suppose qu'il y a un oubli des parenthèses autour de 4n dans l'énoncé initial.

Je sais pas, mais autant ça change pas mal la donne sur le plan "théorique" (voir pos de léon), autant ça va pas changer grand chose concernant l'algo à utiliser pour avoir des valeurs numériques.

Sinon, concernant le "U==0" que j'ai mis dans l'algo., je signale, (vu que visiblement il y en a qui prennent pas la peine de lire entièrement les posts) qu'en dessous, il y a ça :

Le "U0" peut éventuellement être remplacé par un "abs(U)<0.0000000001", mais dans presque tout les langage que je connais, U fini par valoir (assez rapidement) exactement 0.

avec en particulier un mot souligné...

Je rajouterais que ce programme là, plus précisément pour le calcul de exp(x) je l'ai souvent donné à faire (avec le ==) lorsque j’enseignait l'informatique.
A l'époque, je prétendait (à juste titre) que vu la taille limitée (en bits) réservé à l'exposant, ça finirais par faire assez rapidement 0 donc que tant qu'à faire autant aller jusqu'à la limite de la précision de la machine.
Je prétendais aussi (et là, c'est bien moins "vrai") que exp(x) pouvait être trés grand (x=30) ou... trés petit (x=-30) donc qu'on ne savait pas bien quoi mettre comme epsilon dans le fameux abs(U)<epsilon qui aurait du se trouver à la place de U==0
De toute façon, si je leur demandais de programmer ce truc, c'était pour qu'ils le "testent" en faisant afficher la valeur de exp(30) et de 1/exp(-30) puis... qu'il m'expliquent...

[leon1789]

Je ne cherche pas à polémiquer.
Toi, Léon, tu ne fais pas de développent, mais il y a des visiteurs de ce forum qui en font. alors il faut se souvenir de ceci : pour une comparaison d'égalité de deux flottants V1 et v2, il faut faire ceci (langage C, testé aussi avec Excel. PHP, j'ai pas essayé) :
if (fabs(V1 - v2) >.

Oui, j'ai vu ton script.
Fais la même chose en C et on verra.
La variable i est déclarée, on ne sait comment.

Ben si tu ne sais pas, renseigne toi.

Javascript est un langage interprété, donc, à chaque itération une variable prend une valeur disons "affichable", ou arrondie, comme tu voudras.

Et ce n'est pas le cas en C ?? Il n'y a pas d'arrondi en C, les flottants ne sont pas affichables ?

Manifestement tu n'as pas lu le gros document expliquant tout cela. Désolé, j'ai perdu les références. Tu vas me dire "trop facile", comme tu voudras.
Fais le même test sur Excel, et on en reparle.

Et oui c'est pareil avec Excel ! Tu veux un petit exemple qui prouve que tu racontes des choses clairement fausses ?
Avec Excel, le "0 pile" arrive exactement au même moment : après la 324è division par 10 !
Ta mauvaise foi est donc sans limite...

J'aime bien quand tu parles de bonne foi ou de mauvaise foi. :hum:

Effectivement, il y a de quoi ! :ptdr:

Juste une question, et j'aimerais bien que tu répondes : pourquoi penses-tu que j'insiste tellement sur ce point ? Pour contredire des "sachant" comme toi ?

Tu me demandes pourquoi tu insistes en disant que 1.1 divisé par 10^1000 ne fait pas 0 pile, et cela en passant de C à Excel, en dénigrant Javascript, etc.
Parce que tu mélanges un peu tout, que tu ne comprends pas bien, que tu ne veux pas reconnaitre que tu as tord sur un point précis (celui que j'ai critiqué le 25/11/2013 à 16h10 ci-dessus)

C'est marrant, c'est toujours moi qui évoque ce problème, fondamental en informatique.

Oui c'est marrant car tout le monde a compris (que cela soit l'histoire du test ==0, ou l'autre histoire du test "a=b modulo la précision des calculs"), mais toi non, tu portes de fausses conclusions sur le test ==0 car tu penses uniquement au test "a=b modulo la précision"...

[Dlzlogic]

Fait sur C++ :http://codepad.org/oIKR1Nin

A force de diviser par deux un nombre float ou double on arrive bien à 0 exactement.

Bonjour,
Oui, c'est vrai.
Mais, mon propos n'était pas celui-là : c'était seulement de préciser que la comparaison de flottants avec le signe '==' étant en général non valable.
Dans le cas présent : le contre exemple, on arrive à force de boucles à rendre un nombre très petit, donc dépassant les limites de la machine.
Dans mon essai, j'avais un compteur, et je n'arrivais pas à atteindre 0.
Un exemple d'application de cela : soit deux segments qui ont une intersection, que l'on calcule. Le test consiste à vérifier que la distance du point d'intersection à chaque segment est nulle, c'est à dire qu'on s'est pas trompé dans les formules.

Je ne pense pas que le but d'un forum soit de prouver qu'untel ou untel a tort, mais d'aider ceux qui lisent les post.
Un jeune développeur doit avoir le réflexe de faire le test fabs(v1-v2) < epsilon.
Honte à ceux qui disent que c'est pas vrai.
Concernant l'application de cela avec Excel, si mes souvenirs sont exactes, je prenais un segment que je divisais en 2 parties égales et je comparais la longueur des 2 segments ainsi formés. C'est encore plus simple que l'intersection de 2 segments, mais inutilisé dans la pratique.

Pour mémoire, le problème inverse se pose pour des calculs monétaires. C'est à dire qu'il faut calculer des prix en centimes, et donc avec le type long. Ce sujet a été évoqué très en détail, il n'y a pas très longtemps, sur un autre forum. Dans le même esprit je gère les coordonnées X,Y de mon logiciel de CAO/DAO en long et non en flottant. Mais là on sort un peu du sujet.

[Sylviel]

Certes, c'est effectivement ce que j'ai dis dans mon post...

Résumons

1) pour un calcul numérique il faut tester l'égalité sous la forme a = b modulo la précision du calcul. Dans un langage de calcul scientifique c'est parfois implémenté de base, dans un langage générique il faut le faire à la main sous la forme |a-b| < eps

2) tu as pourtant affirmé des contre-vérités, ai monté sur tes grands chevaux en disant qu'on ne cherchait qu'à te contredire sans argumenter (malgré les références aux normes) ni donner d'exemples (malgré un script javascript, dont tu as décrié le langage en conséquence), et invoqué la mauvaise foi de tes contradicteurs.

Pour finir sur un complément intéressant :
il existe des travaux (il me semble que mathématica en a implémenté, mais que les travaux originels sont en FORTRAN) pour pouvoir effectuer des calculs avec une précision arbitraire (dans les rares cas où la précision machine serait insuffisante) et dans ce cadre là diviser un nombre par 10 un nombre fini de fois ne fournira pas un nombre égal à 0... (mais satureras probablement la mémoire vive).

[leon1789]

Mais, mon propos n'était pas celui-là :

Et si, hier, tu as bien tenu ces propos.

Je ne pense pas que le but d'un forum soit de prouver qu'untel ou untel a tort, mais d'aider ceux qui lisent les post.

C'est bien toi qui a écrit > Tu as eu des explications, des exemples, des preuves... Et maintenant, tu dis que ce n'est pas le but du forum.

Un jeune développeur doit avoir le réflexe de faire le test fabs(v1-v2) < epsilon.
Honte à ceux qui disent que c'est pas vrai.

Mais personne n'a dit le contraire... C'est simplement toi qui mêles deux histoires différentes.

Dans mon essai, j'avais un compteur, et je n'arrivais pas à atteindre 0.
Un exemple d'application de cela : soit deux segments qui ont une intersection, que l'on calcule. Le test consiste à vérifier que la distance du point d'intersection à chaque segment est nulle, c'est à dire qu'on s'est pas trompé dans les formules.
(...)

Concernant l'application de cela avec Excel, si mes souvenirs sont exactes, je prenais un segment que je divisais en 2 parties égales et je comparais la longueur des 2 segments ainsi formés. C'est encore plus simple que l'intersection de 2 segments, mais inutilisé dans la pratique.

Pour mémoire, le problème inverse se pose pour des calculs monétaires. C'est à dire qu'il faut calculer des prix en centimes, et donc avec le type long. Ce sujet a été évoqué très en détail, il n'y a pas très longtemps, sur un autre forum. Dans le même esprit je gère les coordonnées X,Y de mon logiciel de CAO/DAO en long et non en flottant. Mais là on sort un peu du sujet.

oui je suis bien d'accord, tout cela sort un petit peu du sujet.

[leon1789]

Pour finir sur un complément intéressant :
il existe des travaux (il me semble que mathématica en a implémenté, mais que les travaux originels sont en FORTRAN) pour pouvoir effectuer des calculs avec une précision arbitraire (dans les rares cas où la précision machine serait insuffisante) et dans ce cadre là diviser un nombre par 10 un nombre fini de fois ne fournira pas un nombre égal à 0... (mais satureras probablement la mémoire vive).

Maple, Mupad permettent aussi de gérer la précision des flottants (jusqu'à des millions de décimales, mais ça finit par ramer sec !)

[Mathusalem]

Bonjour,
Mais là je sors un peu du sujet.

Fixed.
Ce qui t'arrive très souvent quand tu as scandaleusement tort.