Le double contient un flottant avec mantisse et exposant. La taille de la mantisse ne peut contenir la valeur exacte de 10^16 + 1 et donc le +1 est en quelque sorte ignoré.
Pour avoir plus de chiffres significatifs, il faut passer à un truc du genre :
Le double contient un flottant avec mantisse et exposant. La taille de
la mantisse ne peut contenir la valeur exacte de 10^16 + 1 et donc le +1
est en quelque sorte ignoré.
Pour avoir plus de chiffres significatifs, il faut passer à un truc du
genre :
Le double contient un flottant avec mantisse et exposant. La taille de la mantisse ne peut contenir la valeur exacte de 10^16 + 1 et donc le +1 est en quelque sorte ignoré.
Pour avoir plus de chiffres significatifs, il faut passer à un truc du genre :
-- Éric Lévénez FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Samuel DEVULDER
Le 14/10/2012 20:51, ZarkXe a écrit :
Bonjour à tous,
Je du mal a comprend pourquoi 10^16 + 1 - 10^16 = 0 ?
Parce que le double n'a pas assez de précision pour représenter exactement 10^16+1. En effet la mantisse ayant 52bits, on peut représenter exactement les 53 premiers bits des valeurs numériques (1 de plus à cause du bit de poids fort implicite). Or 2^5315, un peu plus petit que 10^16. Donc en mémoire, au format IEEE753, (10^16+1) et (10^16) sont indiscernables. Leur différence fait donc 0.
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour additionner/soustraire les termes par ordre de grandeur décroissante. Ainsi si tu avais fait 10^16 - 10^16 + 1 tu aurais obtenu 1, car (10^16 - 10^16) aurait été évalué en 1er donnant 0, lequel additionné à 1 donne bien 1.
sam.
Le 14/10/2012 20:51, ZarkXe a écrit :
Bonjour à tous,
Je du mal a comprend pourquoi 10^16 + 1 - 10^16 = 0 ?
Parce que le double n'a pas assez de précision pour représenter
exactement 10^16+1. En effet la mantisse ayant 52bits, on peut
représenter exactement les 53 premiers bits des valeurs numériques (1 de
plus à cause du bit de poids fort implicite). Or 2^5315, un peu plus
petit que 10^16. Donc en mémoire, au format IEEE753, (10^16+1) et
(10^16) sont indiscernables. Leur différence fait donc 0.
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour
additionner/soustraire les termes par ordre de grandeur décroissante.
Ainsi si tu avais fait 10^16 - 10^16 + 1 tu aurais obtenu 1, car (10^16
- 10^16) aurait été évalué en 1er donnant 0, lequel additionné à 1 donne
bien 1.
Je du mal a comprend pourquoi 10^16 + 1 - 10^16 = 0 ?
Parce que le double n'a pas assez de précision pour représenter exactement 10^16+1. En effet la mantisse ayant 52bits, on peut représenter exactement les 53 premiers bits des valeurs numériques (1 de plus à cause du bit de poids fort implicite). Or 2^5315, un peu plus petit que 10^16. Donc en mémoire, au format IEEE753, (10^16+1) et (10^16) sont indiscernables. Leur différence fait donc 0.
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour additionner/soustraire les termes par ordre de grandeur décroissante. Ainsi si tu avais fait 10^16 - 10^16 + 1 tu aurais obtenu 1, car (10^16 - 10^16) aurait été évalué en 1er donnant 0, lequel additionné à 1 donne bien 1.
sam.
Lucas Levrel
Le 14 octobre 2012, Samuel DEVULDER a écrit :
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour additionner/soustraire les termes par ordre de grandeur décroissante.
À voir selon le cas. Dans un fil récent, il s'agissait de calculer la somme des 1/k avec k entier. Si on commence par les plus gros (k croissant), au bout d'un moment les additions ne font plus rien (les termes deviennent individuellement négligeables).
Ce qu'il faut faire, me semble-t-il, c'est regrouper les termes de grandeur comparable. Et se méfier des soustractions !
-- LL
Le 14 octobre 2012, Samuel DEVULDER a écrit :
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour
additionner/soustraire les termes par ordre de grandeur décroissante.
À voir selon le cas. Dans un fil récent, il s'agissait de calculer la
somme des 1/k avec k entier. Si on commence par les plus gros (k
croissant), au bout d'un moment les additions ne font plus rien (les
termes deviennent individuellement négligeables).
Ce qu'il faut faire, me semble-t-il, c'est regrouper les termes de
grandeur comparable. Et se méfier des soustractions !
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour additionner/soustraire les termes par ordre de grandeur décroissante.
À voir selon le cas. Dans un fil récent, il s'agissait de calculer la somme des 1/k avec k entier. Si on commence par les plus gros (k croissant), au bout d'un moment les additions ne font plus rien (les termes deviennent individuellement négligeables).
Ce qu'il faut faire, me semble-t-il, c'est regrouper les termes de grandeur comparable. Et se méfier des soustractions !
-- LL
Alexandre Bacquart
On 10/14/2012 09:48 PM, Samuel DEVULDER wrote:
Le 14/10/2012 20:51, ZarkXe a écrit :
Bonjour à tous,
Je du mal a comprend pourquoi 10^16 + 1 - 10^16 = 0 ?
Parce que le double n'a pas assez de précision pour représenter exactement 10^16+1.
Strictement parlant, il n'en a d'ailleurs même pas assez pour représenter exactement 2 ;)
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne sont assez précis).
Le problème peut être résolu de plusieurs manières :
1. Méthode brute : http://gmplib.org/
2. Méthode old-school : utiliser des entiers. Si besoin de fractions, faire de la virgule fixe (fixed point). Imparable, mais pour des valeurs de l'ordre de 10^16, 64 bits est un minimum.
3. Méthode hacker sûr de lui : isoler les calculs flottants sur des petites valeurs et ceux sur des grandes valeurs. Après, le tout est de définir petites et grandes valeurs. Et il vaut mieux avoir une très bonne notion de ce qu'on fait.
-- Alexandre
On 10/14/2012 09:48 PM, Samuel DEVULDER wrote:
Le 14/10/2012 20:51, ZarkXe a écrit :
Bonjour à tous,
Je du mal a comprend pourquoi 10^16 + 1 - 10^16 = 0 ?
Parce que le double n'a pas assez de précision pour représenter
exactement 10^16+1.
Strictement parlant, il n'en a d'ailleurs même pas assez pour
représenter exactement 2 ;)
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande
que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne
sont assez précis).
Le problème peut être résolu de plusieurs manières :
1. Méthode brute : http://gmplib.org/
2. Méthode old-school : utiliser des entiers. Si besoin de fractions,
faire de la virgule fixe (fixed point). Imparable, mais pour des valeurs
de l'ordre de 10^16, 64 bits est un minimum.
3. Méthode hacker sûr de lui : isoler les calculs flottants sur des
petites valeurs et ceux sur des grandes valeurs. Après, le tout est de
définir petites et grandes valeurs. Et il vaut mieux avoir une très
bonne notion de ce qu'on fait.
Je du mal a comprend pourquoi 10^16 + 1 - 10^16 = 0 ?
Parce que le double n'a pas assez de précision pour représenter exactement 10^16+1.
Strictement parlant, il n'en a d'ailleurs même pas assez pour représenter exactement 2 ;)
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne sont assez précis).
Le problème peut être résolu de plusieurs manières :
1. Méthode brute : http://gmplib.org/
2. Méthode old-school : utiliser des entiers. Si besoin de fractions, faire de la virgule fixe (fixed point). Imparable, mais pour des valeurs de l'ordre de 10^16, 64 bits est un minimum.
3. Méthode hacker sûr de lui : isoler les calculs flottants sur des petites valeurs et ceux sur des grandes valeurs. Après, le tout est de définir petites et grandes valeurs. Et il vaut mieux avoir une très bonne notion de ce qu'on fait.
-- Alexandre
Marc Boyer
Le 15-10-2012, Lucas Levrel a écrit :
Le 14 octobre 2012, Samuel DEVULDER a écrit :
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour additionner/soustraire les termes par ordre de grandeur décroissante.
À voir selon le cas. Dans un fil récent, il s'agissait de calculer la somme des 1/k avec k entier. Si on commence par les plus gros (k croissant), au bout d'un moment les additions ne font plus rien (les termes deviennent individuellement négligeables).
Ce qu'il faut faire, me semble-t-il, c'est regrouper les termes de grandeur comparable. Et se méfier des soustractions !
Faut surtout garder en tête que l'analyse numérique est un job à part, et que tant qu'il s'agit de calculer des trucs pour jouer, on peut s'amuser, mais dès que ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta dont les sommes HT + TVA != TTC.
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 15-10-2012, Lucas Levrel <lucas.levrel@u-pec.fr> a écrit :
Le 14 octobre 2012, Samuel DEVULDER a écrit :
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour
additionner/soustraire les termes par ordre de grandeur décroissante.
À voir selon le cas. Dans un fil récent, il s'agissait de calculer la
somme des 1/k avec k entier. Si on commence par les plus gros (k
croissant), au bout d'un moment les additions ne font plus rien (les
termes deviennent individuellement négligeables).
Ce qu'il faut faire, me semble-t-il, c'est regrouper les termes de
grandeur comparable. Et se méfier des soustractions !
Faut surtout garder en tête que l'analyse numérique est un job
à part, et que tant qu'il s'agit de calculer des trucs pour jouer,
on peut s'amuser, mais dès que ça devient sérieux, il faut faire
très attention.
On rapporte toujours l'exemple d'un logiciel de compta
dont les sommes HT + TVA != TTC.
Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Pour éviter ce défaut, il vaut mieux réorganiser les équations pour additionner/soustraire les termes par ordre de grandeur décroissante.
À voir selon le cas. Dans un fil récent, il s'agissait de calculer la somme des 1/k avec k entier. Si on commence par les plus gros (k croissant), au bout d'un moment les additions ne font plus rien (les termes deviennent individuellement négligeables).
Ce qu'il faut faire, me semble-t-il, c'est regrouper les termes de grandeur comparable. Et se méfier des soustractions !
Faut surtout garder en tête que l'analyse numérique est un job à part, et que tant qu'il s'agit de calculer des trucs pour jouer, on peut s'amuser, mais dès que ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta dont les sommes HT + TVA != TTC.
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Antoine Leca
Marc Boyer écrivit :
Faut surtout garder en tête que l'analyse numérique est un job à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Antoine
Marc Boyer écrivit :
Faut surtout garder en tête que l'analyse numérique est un job
à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta
dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Faut surtout garder en tête que l'analyse numérique est un job à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Antoine
Antoine Leca
Alexandre Bacquart écrivit :
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne sont assez précis).
Bzzz ! Je soupçonne une dépendance cachée avec ta machine...
Le problème peut être résolu de plusieurs manières :
1. Méthode brute : http://gmplib.org/
2. Méthode old-school : utiliser des entiers. Si besoin de fractions, faire de la virgule fixe (fixed point). Imparable, mais pour des valeurs de l'ordre de 10^16, 64 bits est un minimum.
3. Méthode hacker sûr de lui : isoler les calculs flottants sur des petites valeurs et ceux sur des grandes valeurs. Après, le tout est de définir petites et grandes valeurs. Et il vaut mieux avoir une très bonne notion de ce qu'on fait.
4. méthode gros bourrin (qui vaut exactement autant que la remarque ci-dessus) : regardez un poil la documentation du compilateur, remarquer que LDBL_DIG y vaut 19 ou 30 ce qui garantit que les opérations utilisent plus de 16 chiffres décimaux significatifs, et utiliser des long doubles...
5. méthode le-gars-des-années-60 : utiliser des flottants "double float" précision doublée fait-maison c'est-à-dire struct {double d[2];} Évidemment toutes les opérations doivent être programmées une par une ; par rapport à GMP dont cette méthode est l'ancêtre, c'est un poil plus rapide en général mais est limité à (environ) 30 chiffres décimaux.
Antoine
Alexandre Bacquart écrivit :
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande
que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne
sont assez précis).
Bzzz ! Je soupçonne une dépendance cachée avec ta machine...
Le problème peut être résolu de plusieurs manières :
1. Méthode brute : http://gmplib.org/
2. Méthode old-school : utiliser des entiers. Si besoin de fractions,
faire de la virgule fixe (fixed point). Imparable, mais pour des valeurs
de l'ordre de 10^16, 64 bits est un minimum.
3. Méthode hacker sûr de lui : isoler les calculs flottants sur des
petites valeurs et ceux sur des grandes valeurs. Après, le tout est de
définir petites et grandes valeurs. Et il vaut mieux avoir une très
bonne notion de ce qu'on fait.
4. méthode gros bourrin (qui vaut exactement autant que la remarque
ci-dessus) : regardez un poil la documentation du compilateur, remarquer
que LDBL_DIG y vaut 19 ou 30 ce qui garantit que les opérations
utilisent plus de 16 chiffres décimaux significatifs, et utiliser des
long doubles...
5. méthode le-gars-des-années-60 : utiliser des flottants "double float"
précision doublée fait-maison c'est-à-dire struct {double d[2];}
Évidemment toutes les opérations doivent être programmées une par une ;
par rapport à GMP dont cette méthode est l'ancêtre, c'est un poil plus
rapide en général mais est limité à (environ) 30 chiffres décimaux.
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne sont assez précis).
Bzzz ! Je soupçonne une dépendance cachée avec ta machine...
Le problème peut être résolu de plusieurs manières :
1. Méthode brute : http://gmplib.org/
2. Méthode old-school : utiliser des entiers. Si besoin de fractions, faire de la virgule fixe (fixed point). Imparable, mais pour des valeurs de l'ordre de 10^16, 64 bits est un minimum.
3. Méthode hacker sûr de lui : isoler les calculs flottants sur des petites valeurs et ceux sur des grandes valeurs. Après, le tout est de définir petites et grandes valeurs. Et il vaut mieux avoir une très bonne notion de ce qu'on fait.
4. méthode gros bourrin (qui vaut exactement autant que la remarque ci-dessus) : regardez un poil la documentation du compilateur, remarquer que LDBL_DIG y vaut 19 ou 30 ce qui garantit que les opérations utilisent plus de 16 chiffres décimaux significatifs, et utiliser des long doubles...
5. méthode le-gars-des-années-60 : utiliser des flottants "double float" précision doublée fait-maison c'est-à-dire struct {double d[2];} Évidemment toutes les opérations doivent être programmées une par une ; par rapport à GMP dont cette méthode est l'ancêtre, c'est un poil plus rapide en général mais est limité à (environ) 30 chiffres décimaux.
Antoine
Samuel DEVULDER
Le 15/10/2012 14:23, Alexandre Bacquart a écrit :
On 10/14/2012 09:48 PM, Samuel DEVULDER wrote:
Le 14/10/2012 20:51, ZarkXe a écrit :
Bonjour à tous,
Je du mal a comprend pourquoi 10^16 + 1 - 10^16 = 0 ?
Parce que le double n'a pas assez de précision pour représenter exactement 10^16+1.
Strictement parlant, il n'en a d'ailleurs même pas assez pour représenter exactement 2 ;)
Je ne comprends pas. Typiquement 2 sera représenté par les bits suivants sur un float 32bit ieee 754:
Dans l'exemple s=0, mantisse=0, expo8, donc value=2 exactement.
Plus généralement parlant tous les entiers de 0 à 2^23-1 peuvent être représentés et ajoutés ou soustraits sans erreur sur un float32 (la mantisse contient assez de bits pour cela), et jusqu'à 2^53-1 sur un float64. (je ne compte pas les nombres dénormalisés).
Un bon exemple pour jouer avec le format IEEE est de coder une implémentation d'une représentation minifloat 8bits 1.4.3 (http://en.wikipedia.org/wiki/Minifloat). C'est très marrant, il n'y a que 242 valeurs possibles mais elles s'étalent de -122880 à 122880, soit une amplitude plus grande que 16bits. On peut y représenter exactement tous les entiers de -16 à +16. C'est pas mal avec si peu de bits!
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne sont assez précis).
Oui, en plus je pense le résultat dépend du mode d'arrondi de l'unité flottante ou si elle travaille sur un format étendu en interne ou pas.
sam.
Le 15/10/2012 14:23, Alexandre Bacquart a écrit :
On 10/14/2012 09:48 PM, Samuel DEVULDER wrote:
Le 14/10/2012 20:51, ZarkXe a écrit :
Bonjour à tous,
Je du mal a comprend pourquoi 10^16 + 1 - 10^16 = 0 ?
Parce que le double n'a pas assez de précision pour représenter
exactement 10^16+1.
Strictement parlant, il n'en a d'ailleurs même pas assez pour
représenter exactement 2 ;)
Je ne comprends pas. Typiquement 2 sera représenté par les bits suivants
sur un float 32bit ieee 754:
Dans l'exemple s=0, mantisse=0, expo8, donc value=2 exactement.
Plus généralement parlant tous les entiers de 0 à 2^23-1 peuvent être
représentés et ajoutés ou soustraits sans erreur sur un float32 (la
mantisse contient assez de bits pour cela), et jusqu'à 2^53-1 sur un
float64. (je ne compte pas les nombres dénormalisés).
Un bon exemple pour jouer avec le format IEEE est de coder une
implémentation d'une représentation minifloat 8bits 1.4.3
(http://en.wikipedia.org/wiki/Minifloat). C'est très marrant, il n'y a
que 242 valeurs possibles mais elles s'étalent de -122880 à 122880, soit
une amplitude plus grande que 16bits. On peut y représenter exactement
tous les entiers de -16 à +16. C'est pas mal avec si peu de bits!
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande
que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne
sont assez précis).
Oui, en plus je pense le résultat dépend du mode d'arrondi de l'unité
flottante ou si elle travaille sur un format étendu en interne ou pas.
Dans l'exemple s=0, mantisse=0, expo8, donc value=2 exactement.
Plus généralement parlant tous les entiers de 0 à 2^23-1 peuvent être représentés et ajoutés ou soustraits sans erreur sur un float32 (la mantisse contient assez de bits pour cela), et jusqu'à 2^53-1 sur un float64. (je ne compte pas les nombres dénormalisés).
Un bon exemple pour jouer avec le format IEEE est de coder une implémentation d'une représentation minifloat 8bits 1.4.3 (http://en.wikipedia.org/wiki/Minifloat). C'est très marrant, il n'y a que 242 valeurs possibles mais elles s'étalent de -122880 à 122880, soit une amplitude plus grande que 16bits. On peut y représenter exactement tous les entiers de -16 à +16. C'est pas mal avec si peu de bits!
Les propriétés des flottants font qu'ajouter 1 à une valeur aussi grande que 10^16 n'aura vraisemblablement aucun effet (ni float ni double ne sont assez précis).
Oui, en plus je pense le résultat dépend du mode d'arrondi de l'unité flottante ou si elle travaille sur un format étendu en interne ou pas.
sam.
Marc Boyer
Le 15-10-2012, Antoine Leca a écrit :
Marc Boyer écrivit :
Faut surtout garder en tête que l'analyse numérique est un job à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Ben, que (x) et (x * (1-e)) + (x*e) ne sont pas garantis comme égaux en flottant, même pour des valeurs asez "assez peu" de chiffres significatifs (une TVA, c'est 4 chiffres significatifs et une facture chez le commun des mortel dépasse rarement les 10 chiffres).
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 15-10-2012, Antoine Leca <root@localhost.invalid> a écrit :
Marc Boyer écrivit :
Faut surtout garder en tête que l'analyse numérique est un job
à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta
dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Ben, que (x) et (x * (1-e)) + (x*e) ne sont pas garantis comme égaux
en flottant, même pour des valeurs asez "assez peu" de chiffres
significatifs (une TVA, c'est 4 chiffres significatifs et une facture
chez le commun des mortel dépasse rarement les 10 chiffres).
Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Faut surtout garder en tête que l'analyse numérique est un job à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Ben, que (x) et (x * (1-e)) + (x*e) ne sont pas garantis comme égaux en flottant, même pour des valeurs asez "assez peu" de chiffres significatifs (une TVA, c'est 4 chiffres significatifs et une facture chez le commun des mortel dépasse rarement les 10 chiffres).
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Antoine Leca
Marc Boyer écrivit :
Le 15-10-2012, Antoine Leca a écrit :
Marc Boyer écrivit :
Faut surtout garder en tête que l'analyse numérique est un job à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Ben, que (x) et (x * (1-e)) + (x*e) ne sont pas garantis comme égaux en flottant, même pour des valeurs asez "assez peu" de chiffres significatifs (une TVA, c'est 4 chiffres significatifs et une facture chez le commun des mortel dépasse rarement les 10 chiffres).
On est hors sujet mais je continue un peu : il me paraît évident (depuis de nombreuses années, donc avant de programmer en C) que les applications de comptabilité ne doivent pas manipuler les montants en utilisant directement les types flottants, parce que les chiffres décimaux après la virgule n'ont pas de représentation unique.
Comme en C il n'y a/avait pas de virgule fixe, cela ne laissait que les type entiers ; autrement dit en C89 au maximum 7+2 chiffres significatifs ce qui était insuffisant. D'où l'idée proposée par certains d'utiliser le type double qui garantit 15 chiffres, suffisant en pratique en comptabilité *si on prend garde à calculer en centimes* (ou en millimes voire décimillimes). Les doubles ne sont alors utilisée que comme des entiers avec une étendue de 53 bits (cf. le message de Samuel); évidemment depuis C99 cela n'est plus nécessaire (à supposer que beaucoup de fous ont programmé de la compta en C).
À propos du nombre de chiffres, un total de bilan en pesètes ou en lires atteint sans difficulté 11 chiffres avant la virgule... C'est vrai qu'avec l'euro on est revenu avec des sommes plus facile à manipuler, mais il existe toujours des pays où on peut avoir besoin de plus de chiffres (un milliard de yens ou de francs CFA/CFP n'est pas une facture irréaliste).
À propos de calcul de TVA, pour moi la TVA est toujours en centimes (même si la manière d'arrondir peut être l'objet de discussions «intéressantes» avec le fisc...) Par contre, la formule HT + TVA != TTC peut apparaître quand tu dois recalculer le montant HT à partir du TTC: il est des fois où cela ne tombe pas juste !
Antoine
Marc Boyer écrivit :
Le 15-10-2012, Antoine Leca <root@localhost.invalid> a écrit :
Marc Boyer écrivit :
Faut surtout garder en tête que l'analyse numérique est un job
à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta
dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Ben, que (x) et (x * (1-e)) + (x*e) ne sont pas garantis comme égaux
en flottant, même pour des valeurs asez "assez peu" de chiffres
significatifs (une TVA, c'est 4 chiffres significatifs et une facture
chez le commun des mortel dépasse rarement les 10 chiffres).
On est hors sujet mais je continue un peu : il me paraît évident (depuis
de nombreuses années, donc avant de programmer en C) que les
applications de comptabilité ne doivent pas manipuler les montants en
utilisant directement les types flottants, parce que les chiffres
décimaux après la virgule n'ont pas de représentation unique.
Comme en C il n'y a/avait pas de virgule fixe, cela ne laissait que les
type entiers ; autrement dit en C89 au maximum 7+2 chiffres
significatifs ce qui était insuffisant. D'où l'idée proposée par
certains d'utiliser le type double qui garantit 15 chiffres, suffisant
en pratique en comptabilité *si on prend garde à calculer en centimes*
(ou en millimes voire décimillimes). Les doubles ne sont alors utilisée
que comme des entiers avec une étendue de 53 bits (cf. le message de
Samuel); évidemment depuis C99 cela n'est plus nécessaire (à supposer
que beaucoup de fous ont programmé de la compta en C).
À propos du nombre de chiffres, un total de bilan en pesètes ou en lires
atteint sans difficulté 11 chiffres avant la virgule... C'est vrai
qu'avec l'euro on est revenu avec des sommes plus facile à manipuler,
mais il existe toujours des pays où on peut avoir besoin de plus de
chiffres (un milliard de yens ou de francs CFA/CFP n'est pas une facture
irréaliste).
À propos de calcul de TVA, pour moi la TVA est toujours en centimes
(même si la manière d'arrondir peut être l'objet de discussions
«intéressantes» avec le fisc...) Par contre, la formule HT + TVA != TTC
peut apparaître quand tu dois recalculer le montant HT à partir du TTC:
il est des fois où cela ne tombe pas juste !
Faut surtout garder en tête que l'analyse numérique est un job à part, [...] ça devient sérieux, il faut faire très attention.
On rapporte toujours l'exemple d'un logiciel de compta dont les sommes HT + TVA != TTC.
Et le rapport avec soit le langage C, soit l'analyse numérique est ?
Ben, que (x) et (x * (1-e)) + (x*e) ne sont pas garantis comme égaux en flottant, même pour des valeurs asez "assez peu" de chiffres significatifs (une TVA, c'est 4 chiffres significatifs et une facture chez le commun des mortel dépasse rarement les 10 chiffres).
On est hors sujet mais je continue un peu : il me paraît évident (depuis de nombreuses années, donc avant de programmer en C) que les applications de comptabilité ne doivent pas manipuler les montants en utilisant directement les types flottants, parce que les chiffres décimaux après la virgule n'ont pas de représentation unique.
Comme en C il n'y a/avait pas de virgule fixe, cela ne laissait que les type entiers ; autrement dit en C89 au maximum 7+2 chiffres significatifs ce qui était insuffisant. D'où l'idée proposée par certains d'utiliser le type double qui garantit 15 chiffres, suffisant en pratique en comptabilité *si on prend garde à calculer en centimes* (ou en millimes voire décimillimes). Les doubles ne sont alors utilisée que comme des entiers avec une étendue de 53 bits (cf. le message de Samuel); évidemment depuis C99 cela n'est plus nécessaire (à supposer que beaucoup de fous ont programmé de la compta en C).
À propos du nombre de chiffres, un total de bilan en pesètes ou en lires atteint sans difficulté 11 chiffres avant la virgule... C'est vrai qu'avec l'euro on est revenu avec des sommes plus facile à manipuler, mais il existe toujours des pays où on peut avoir besoin de plus de chiffres (un milliard de yens ou de francs CFA/CFP n'est pas une facture irréaliste).
À propos de calcul de TVA, pour moi la TVA est toujours en centimes (même si la manière d'arrondir peut être l'objet de discussions «intéressantes» avec le fisc...) Par contre, la formule HT + TVA != TTC peut apparaître quand tu dois recalculer le montant HT à partir du TTC: il est des fois où cela ne tombe pas juste !
