Calcul d'erreur

[busard_des_roseaux]

Bonjour,


j'ai la boucle de programme suivante qui calcule une valeur approchée de .

Les calculs se font exclusivement sur l'ensemble nombres décimaux positifs à N décimales après la virgule, selon les règles d'arrondi usuelles.

On pose .

désigne une valeur approchée positive, à près, du réel x .

---------------------------------------------------------------------
EXP():
INPUT




WHILE

calcul de la somme de la série

calcul de la puissance

on divise par la factorielle

on incrémente de 1

ENDWHILE
STOP
--------------------------------------------------------------------

J'aurai souhaité calculer un majorant de l'erreur commise.



cordialement,

[alben]

Bonjour,
Sous réserve de vérification plus précise, il me semble que ton erreur n'est pas bornée.
Tel que tu le présentes ton algorithme est remarquablement inefficace. Si x est assez grand, le nombre de pas va être immense d'autant que tu as pris comme condition d'arrêt de la boucle U<10^-N. Avec les arrondis, il est possible que cette condition ne soit jamais remplie.
En virgule flottante, si b est ta base (2 en binaire, 10 en décimale) tu peux déjà poser p=valeur entière la plus proche de x/ln(b) et x'=x-p.ln(b. On a donc
. Cela te permet de limiter ton calcul à des valeurs de x inférieures en valeur absolue à ln(b)/2 (0,35 en binaire).

[busard_des_roseaux]

Tel que tu le présentes ton algorithme est remarquablement inefficace.

Bjr Alben, tu as à la fois raison et tort.

tort, car les séries de Taylor m'ont permis de programmer tous les calculs usuels avec 800 décimales, le temps de réponse étant inférieur à la seconde, ce qui me convient dans bien des cas.
raison, car avec ce type d'algorithme, il est tout à fait impossible, en pratique, de dépasser le millier de décimales, les temps de réponse croissant exponentiellement avec le nombre de décimales souhaité.

En virgule flottante, si b est ta base (2 en binaire, 10 en décimale) tu peux déjà poser p=valeur entière la plus proche de x/ln(b) et x'=x-p.ln(b). On a donc . Cela te permet de limiter ton calcul à des valeurs de x inférieures en valeur absolue à ln(b)/2 (0,35 en binaire).

merçi beaucoup pour cette optimisation.
Effectivement, ln(b) peut être calculé , une fois pour toutes.

ça m'intéresse d'avoir un majorant de l'erreur commise. Je pensais utiliser des différentielles pour les calculs élémentaires (additions, multiplications, divisions) et programmer un cumul de ces incertitudes dans la boucle
WHILE.
Idées à ce propos ?
De plus, doit être de l'ordre de d'après un calcul de différentielle.


cordialement,

[alben]

Bonsoir,
En supposant que tu appliques l'astuce que j'ai proposée, x est au plus de 1.15 (en décimal) et le nième terme du développement sera de l'ordre de qui doit être égal à .
En passant au log décimal, on a donc N=n.log(n/3) équation qui n'a pas de solution directe mais pour des N voisins de 800, log(n/3) peut être minoré par 2 et n=N/2.
Autrement dit, pour une telle précision, il te faut calculer N/2 termes (cette majoration marche à partir de N>620).
L'erreur sur les multiplications et divisions n'a pas d'impact puisqu'elle portent sur des décimales qui seront igorées lors des additions. Il te reste donc une erreur de sommation qui sera inférieure à .
Donc, au total sauf si...
Sauf si tu t'acharne à fixer ta limite de boucle aussi basse. Tu risques de calculer des termes (beaucoup) inutiles qui alourdiront ton erreur. En prenant un seuil cinq fois plus fort, tu auras une meilleure précision.
Mais je maintiens que tes séries de Mc Laurin ne sont pas très efficaces : 1 seconde c'est long...
D'ailleurs une autre astuce est de remarquer que exp(2x)=[exp(x)]² : mettre au carré ton résultat te fait perdre un peu de précision mais te fait économiser plus de 10 % des calculs (et donc des erreurs).
En ce qui concerne l'expentielle, les programmes les plus efficaces utilisent les approximants de Padé ou les fractions continues...