Version imprimable
Bonjour,
Pour simuler un dosage pH-métrique en chimie il est parfois nécessaire de manier des chiffres avec un très grand nombre de chiffres significatifs (disons jusqu'à 40). Or même en travaillant avec type long double on ne peut pas atteindre ce nombre de chiffres significatifs.
Y a-t-il un moyen de contourner cette limitation ?
Merci à vous.
Par chiffres significatifs je suppose que tu raisonnes en base 10 ?
Il n'y a pas de solution en C natif : il faut implémenter un système dédié pour stocker ces « grands » nombres et effectuer des opérations avec. Des bibliothèques existent, par exemple decNumber (premier résultat en cherchant « decimal number library c »).
Oui, de deux manières: avec des doubles, ou avec ce qu'on appelle parfois BigInteger: manipuler des nombres sous forme de chaine de caractère.
Cela dit, 40 digits, c'est une précision à 10 puissance 40. C'est aussi précis que le rapport de taille entre un atome et le soleil au carré.
A titre de comparaison, la lumière émise il y a 2000 ans n'a avancé que de 3*1027 nanomètres.
Autre point de comparaison, 2 grammes de carbone contient 1023 atomes.
Pour avoir un nombre à 40 chiffres d'atomes, il faut une masse de carbone de l'ordre de la tera-tonne. On parle de la masse de carbone censée exister dans l'ensemble de l'atmosphère terrestre. ou encore d'un bol d'étoile à neutron, ou de cent fois la masse totale des poissons (d'après wikipedia)
40 chiffres significatifs, ca n'a guère de sens pour un dosage pH, sauf à doser une mer.
Il bosse peut-être dans l'homéopathie ? :mrgreen:
Cela a un sens quand tu veux faire le calcul sans approximation (ce qui est mon cas) est que tu as un terme Ke.Ka1.Ka2.Ka3 pour un polyacide.
Exemple déjà avec un acide faible simple. Si pKa n'est pas trop grand :
https://gyazo.com/d49158767b49c265e6c2c3d48b6c3e59
Si pKa devient grand :
https://gyazo.com/a0c46e1dc79f82bdf235dd4960568409
Je cherche donc à résoudre ce problème ;)
Sans approximation, mais en travaillant avec des doubles, ou des entiers à 40 chiffres?
Avec des nombres à 40 significatifs, et en quantifiant à la bonne échelle, tes nombres sont tous multiples de 10-40
Partant de là, tu peux tout écrire comme des nombres entiers de cette unité-là (10-40).
Travaille avec des long long, et c'est bouclé.
Le problème d'un float et d'un double, c'est qu'un certain nombre de bits sont utilisés pour l'ordre de grandeur.
Le problème adjacent, c'est que toute opération entre nombre d'ordre de grandeur différent est empreint d'erreur.
Les long long sont sensé pouvoir contenir des entiers jusqu'à 1018
long long double ça existe ?
En lisant les doc j'avais cru comprendre que cela n'existait que pour le type int.
Bonjour,
Non, ça n'a aucun sens de vouloir connaître un pH avec une telle précision, quoi que tu puisses en dire. :(Citation:
Envoyé par asanque
nope !Citation:
Cela dit, 40 digits, c'est une précision à 10 puissance 40.
6.02e+23 -> 3 chiffres significatifs
Il ne faut pas faire la confusion !
un double c'est 15 chiffre significatifs (mantisse de 52+1 bit)
Pour 40 chiffres significatifs il faudrait une mantisse de 132 bits environs (il faut que je refasse le calcul).
Un long double n'a pas une pécision très portable...
Il faut passer par une librairie (GMP par exemple)
Où coder son grand nombre soi-même ( ce qui complique pas mal les choses)
Merci de la précision.
Du coup je n'ai même pas besoin de chercher plus que double pour les chiffres significatifs. Reste à comprendre d'où vient le problème quand les nombres calculés sont petits vu que ça n'a pas l'air d'être ce que je croyais.
Le problème des doubles, c'est qu'ils sont imprécis par rapport aux nombres que les mathématiques qualifient de réels.
Notamment, lorsque des additions sont faites entre nombre d'ordre différents, ou lors de multiplications de nombre ayant beaucoup (pour des doubles) de chiffres significatifs.
Quand je parlais d'Avogadro, c'est parce que je parlais de nombre tels que 1 000 000 000 000 000 000 000 000 000 000 000 000 000 1.
Ce qui est affreusement plus précis qu'une mole et un: 602 000 000 000 000 000 001
Normalement, tout au long de tes calculs, tes imprécisions doivent se compenser et se fondre dans un « bruit ambiant » qui s'annule lui-même. Si tu fais des itérations et que cela amplifie l'erreur, alors c'est de ce côté qu'il faudra creuser avant de penser à utiliser des nombres plus grands.Citation:
Envoyé par asanque
Ensuite, il faut savoir que les nombres à virgule flottante des ordinateurs sont codés en binaire, ce qui signifie entre autres choses qu'un nombre fini en décimal peut ne pas l'être en binaire. Par exemple, s'il est tout-à-fait possible d'écrire 1,5 en binaire (soit 1,1b), il n'est pas possible d'y représenter « 1,2 » de façon exacte : cela donne 1,00110011001100110011… à l'infini, de la même façon que « 4÷3 » donne 1,33333333333… en décimal. En principe, ce n'est pas un problème sur un nombre à virgule flottante suffisamment grand, mais c'est quelque chose qu'il faut garder à l'esprit.
Enfin, les précisions de float et a fortiori de double sont très honorables, et la gamme des ordres de grandeur que l'on peut y représenter est très vaste. Par contre, si tu essaies de faire des opérations avec des nombres dont l'écart d'ordre de grandeur est plus grand que la précision du type choisi, alors le plus petit des deux sera considéré comme négligeable par rapport à l'autre et donc nul. Avec float, on peut représenter un milliard « 1 000 000 000 » mais pas « 1 000 000 001 ». Ça veut dire que si x vaut un milliard (ou toute valeur de cet ordre de grandeur ou supérieur), alors « x = x + 1 » ne donnera aucun résultat et laissera x inchangée. Avec double, le problème est le même mais il faut monter nettement plus haut avant que l'unité devienne négligeable.
Fais une recherche avec « What Every Scientist Should Know About Floating-Point Arithmetic ».
Le problème vient probablement de là. Puisque les coefficients de l'équation mathématique à résoudre sont de 1e0 ; 1e-5 ; -1.0000001e-7 et le dernier d. Dès que je modifie les paramètres et que d devient inférieur à -1e-20 alors les résultats divergent très sensiblement de ceux attendus.Code:faire des opérations avec des nombres dont l'écart d'ordre de grandeur est plus grand que la précision du type choisi
Merci ;)
J'ai commencé à lire le doc mais il est touffu, va falloir du temps.