Comments on Pourquoi ne pas faire confiance à une calculatrice

Concernant ta remarque sur les impôts, apparemment en Allemagne la fonction d'imposition n'est pas affine par morceaux comme en France, mais quadratique comme tu le souhaites :

<URL: http://www.tagesschau.de/inland/kalte-progression-103.html >
Il y est dit: "Das ist eine nicht-lineare, quadratische Formel…"

Un autre post pour deux autres exemples.

Tout d'abord, sous Sage, print 0.1 + 0.2 vous affichera 0.30000000000000004 . J'ai un document qui explique que pour Sage, 0.1 + 0.2 est arrondi à 1351079888211149/4503599627370496 , une fraction qui est ensuite traduite en approximation décimale sous 0.30000000000000004. C'est à cela que sert le calcul formel, limité l'emploi de calculs numériques approchés. L'idéal, tout comme avec les sondages, seraient que l'utilisateur est un affichage du type environ égal avec une erreur de temps.

Voici un petit programme Python que je vous invite à traduire dans un langage ne faisant pas du calcul formel.

A = 1.0

while ((A + 1.0) - A == 1.0):

A *= 2.0

print("A = ", A)

B = 1.0

while ((A + B) - A != B):

B += 1.0

print("B = ", B)

Python 3 affiche A = 9007199254740992.0 et B = 2.0.

Les erreurs de calcul sont inhérentes à l'utilisation de flottants qui sont en nombre fini.

À cette adresse http://sagebook.gforge.inria.fr/ , vous trouverez un PDF qui propose l'exemple suivant de niveau 2nde.

Sous Sage, le code suivant renverra 1/3 comme attendu (en espérant que la mise en forme sera respecté).

u = 1/3

for i in range(100):

u = 4*u - 1

print u

Par contre, en changeant u = 1/3 en u = 1.0/3, ce qui a pour effet que Sage fera des calculs approchés, la sortie devient -2.97343269313742e43 !

Calculer (1+1/x)^x est un exemple assez courant pour les erreurs d’arrondis : ça tends vers e, et c’est même une méthode assez efficace pour calculer e, mais ça commence à s'en éloigner(avec des nombres à virgule flottante IEEE 754) pour x≥1e8 et c’est vraiment visible pour x≥1e15.

Un autre exemple, qui correspond à de « vrais » calculs, c’est la formule donnant les racines du trinôme ax²+bx+c=0. La formule usuelle (b±√(b²-4ac))/2a donne de très mauvais résultats si ac<<b pour une des deux racines, ce qui se voit si on compare numériquement le produit des racines avec sa valeur théorique (c/a).

Soit ( 2^1/2+3^1/2)^2000

Question : quels sont les 2 chiffres avant et après la virgule ?

C'est assez simple de répondre à la question en utilisant des astuces et connaissances de base ( niveau terminale je pense ) , par contre je ne pense pas qu'une calculatrice puisse aider à répondre à la question. Mais je me trompe peut être.

Oups, rajouter un zéro : Google nous dit 1000000000000000 + 1 - 1000000000000000 = 0

La calculatrice de Google se plante pour 100000000000000 + 1 - 100000000000000, qui me semble un peu plus direct d'un point de vue pédagogique.

Mais quand allez vous arrêter de dire que tel soft se plante ou que "c'est faux"??

C'est aussi idiot que de dire que 1+1=0 est faux alors qu'on calcule juste dans Z/2Z et non pas sur R.

IEEE 754 ce n'est pas R. C'est une trivialité mais ça m’empêche pas de lire encore et encore que "tel soft renvoie un résultat faux"…ce qui est faux.

Le problème étant de savoir exactement selon quelle norme le soft qu'on utilise calcule. Ce n'est pas toujours évident et ensuite il faut encore arriver à en dire des choses digne d’intérêt.

@PB : J'achète !

Ces résultats ne sont pas faux!
On n'est pas sur les réels mais sur des floatants.
J'ai un stagiaire qui avait une fonction de Cost(x) à optimiser.
Cost(1) renvoie 0.0. Pour voir un peu comment tout ça varie, il avait écrit:
x=-1
for i in range(10):
x = x + i/10.
print(Cost(x))
et il se demandait "mais pourquoi ça n'affice pas exactement 0.0 quand x vaut 1 ???"

Un jour peut-être ont apprendra aux gens ***que ces machins ne calculent pas sur R***. Pour commencer, il faudrait arreter de dire que ces machins renvoient des résultats faux. C'est idiot. Ils font exactement ce que la norme sur les floatants veut qu'ils fassent. Dire que c'est un "résultat faux" est anti-pédagogique au possible :(

Je ne connaissais pas cet exemple, mais j'en connais un bien rigolo aussi, très simple.

on prend la suite u_n définie de la façon suivante :
u_0 = e-1
u_n = n * u_{n-1} - 1

On peut montrer (ce n'est pas très difficile) que cette suite converge vers 0 (en 1/n).
Par contre, si u_0 change un tout petit peu (par exemple à cause d'une approximation de e), alors la suite diverge violemment (en n!, vers plus ou moins l'infini selon si l'approximation était au dessus ou en dessous).

Résultat : n'importe quelle calculatrice ou logiciel de calcul (utilisant une valeur approchée de e, aussi fine soit-elle) se plante joyeusement, tandis que le mathématicien s'en sort. :) J'ai testé, c'est assez rigolo.

@RRt : en effet, je n'ai pas dit comment on peut montrer que (1+sqrt(2))²⁰⁰+(1-sqrt(2))²⁰⁰ est un entier *sans* développer avec la formule du binôme. Voici : il y a une application de l'anneau Z[sqrt(2)] dans lui-même qui s'appelle la conjugaison et qui est très sympathique :-)

@Anna: une autre preuve que j'aime bien consiste à remarquer que 1 + sqrt(2) et 1 + sqrt(2) sont les racines conjuguées du polynôme x^2 - 2x - 1. Donc la suite de terme général (1+sqrt(2))^n + (1-sqrt(2))^n vérifie la relation de récurrence u_(n+2) = 2 u_(n+1) + u_n . La parité se montre alors simplement par récurrence.

À l'inverse, il peut arriver que la machine donne un résultat correct auquel on ne s'attend pas.
Cela m'est arrivé avec Sage[1] : j'avais une fonction définie par l'aire entre 0 et x sous une certaine fonction et j'avais besoin de la tracer.

Je donne donc la fonction à Sage, lui demande d'intégrer entre 0 et x et puis demande de tracer en fonction de x. Bang, ça ne marche pas, il fait une erreur un peu cryptique …

En fouillant j'ai remarqué que Sage prenait ln(x) comme primitive de 1/x et non ln(|x|), avec comme convention que ln(-1)=i*pi ; donc la fonction que je devais tracer avait une composante imaginaire constante i*pi.

Certes, Sage ne s'est pas trompé, mais cela a quand même ébranlé ma confiance en lui.

Il y a aussi celle-ci :

sage: f(x)=1/x
sage: limit(f,x=0)
x |--> Infinity

Il donne Infinity comme limite de 1/x pour x->0.
Encore une fois, ce n'est pas une faute parce qu'il distingue +Infinity, -Infinity et Infinity (sans signe).
Avec la topologie idoine sur R u {infinity}, oui on a 1/x->infinity pour x->0…

Mais je crois qu'il y a des étudiants de première année qui pourraient être sérieusement ébranlés par ce genre de plaisanteries de la part d'un logiciel de calcul formel.

[1] www.sagemath.org

Un exemple du type sin(10^50×π+1), qui vaut clairement sin(1) me paraît plus parlant, mais ce n'est que mon avis.

Sinon, ton exemple me fait remarquer que la calculatrice de Google n'est vraiment pas terrible : pour le calcul du membre de droite, elle donne la bonne valeur pour (1-sqrt(2))^200×π, mais son sinus vaut… 0 !
En fait, il semble que le calcul de sin(x) rende 0 dès que x est plus strictement plus petit en valeur absolue que 10^-14, alors que dans ces cas le résultat devrait être x.

@PB : Dans ton calcul, il faut montrer que x est congru à 0 modulo 2 *et* que y est nul. Pour ça, la solution la plus rapide me semble bien être de passer par la formule du binôme.

Je n'ai pas de calculatrice sous la main pour tester des choses plus élémentaires comme ln(e^(-100)+1-1). Je n'ai pas réussi à le faire comprendre à google et scilab n'y arrive pas.

@Annna :

L'application f de Z[sqrt(2)] dans Z/2Z qui associe à x+y*sqrt(2) la classe de x modulo 2 est un morphisme d'anneaux (pour le vérifier sans faire le moindre calcul : identifier Z[sqrt(2)] à Z[X]/(X²-2) et voir que f provient d'un morphisme évident par passage au quotient).

Enfin : f((1+sqrt(2))²⁰⁰+(1-sqrt(2))²⁰⁰)=f(1+sqrt(2))²⁰⁰+f(1-sqrt(2))²⁰⁰=1+1=0.

4,1-4-0,1

Sur libreoffice, ça donne un peu moins que zéro : -3,60822483003176*10^-16

Pour la parité de la somme, la formule du binôme est ce qu'il y a de plus efficace/rapide ?

J'aurais cru que le PACS ou le mariage revenant à calculer le taux d'imposition sur la moyenne des revenus des deux partenaires, on y gagnait forcément? Ou alors vous touchez exactement le même salaire tous les deux? (Peu plausible.)

je ne connaissais pas cet exemple mais effectivement toute formule dans laquelle intervient un très grand nombre ou un très petit est potentiellement dangereuse

J'utilise souvent "The right way to calculate stuff" (http://www.plunk.org/~hatch/rightway.php) lorsqu'un tel risque pourrait exister dans mon code…

Comment avez vous obtenu "la valeur correcte" ? Pour ma part j'ai essayé Python (faux, sans surprise) et ma calculatrice préférée http://www.speedcrunch.org/ qui m'a un peu déçue : elle a renvoyé NaN (Not a Number) alors qu'elle est censée travaillaer avec autant de décimales que nécessaire. En creusant j'ai vu qu'elle s'en sort "presque" :

(sqrt(2)+1)^200=35903523178476671398039972962187754894463006960216912732142716329467686943874.003

mais ensuite elle n'arrive pas à calculer le sinus de ça (*pi)

Le seul outil que j'utilise (pas assez apparemment) qui m'ait donné la "bonne" valeur est Wolfram Alpha (donc Mathematica doit probablement s'en sortir aussi):

http://www.wolframalpha.com/input/?i=sin%28%28sqrt%282%29%2B1%29%5E200*pi%29

Effet Zahir, forever

J'ai fait, assez récemment, le test d'afficher sin(2*x)-2*sin(x)*cos(x)
pour x entier entre 1 et 10 en Groovy (~ Java).
Et bien cela ne retourne pas toujours 0. Cela me chagrine quelque peu.
(bon, l'explication doit être plus simple [encodage des "double" en IEEE…],
mais quand même…)

Alors visiblement, j'ai la preuve que je ne suis pas un mathématicien compétent.
Ce qui pose la question de savoir si je suis un mathématicien incompétent, ou si je serai en fait un informaticien, comme le prétend mon contrat de thèse et le nom de mon laboratoire. (Ou alors peut-être un logicien)

Plus sérieusement, c'est marrant, j'ai du mal à réaliser si la capacité à réaliser de tels calculs et approximation est vraiment une compétence indispensable pour un mathématicien, même quand le domaine de recherche en est très éloigné.