Différence bizarre d'un calcul avec variables intermédiares

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour,
J' ai un phénomène très bizarre que j'explique pas, à vous de juger.

On a deux objets, Foo et Bar :
Code:

1 2 3 4 5 6 7 8 9 10 11 class Foo { double getX() { return (m_X); } double getY() { return (m_Y); } };
Code:

1 2 3 4 5 6 7 class Bar { double getValue() { return (m_value); } };
Maintenant, ce qu'il y a de bizarre, c'est qu'en faisait cela:
Code:

1 2 result = (Foo.getX() - Bar.getValue()/2 + Foo.getY()/2)/Foo.getX(); // result = 0.17271511157289223814537137968728
Et cela:
Code:

1 2 3 4 5 double x = Foo.getX(); double value = Bar.getValue(); double y = Foo.getY(); result = (x - value/2 + y/2)/x; // result = 0.17271511157289287652361053915229
On obtient pas le même resultat comme vous pouvez le voir.
Code:

1 2 // result = 0.17271511157289223814537137968728 // result = 0.17271511157289287652361053915229
Je ne comprends vraiment pas car les getters() ne font que renvoyer la valeurs et rien de plus.
Si quelqu'un à une explication, je suis preneur.

Merci de votre aide.

11/12/2012, 13h38
r0d

Est-ce que les variables membre m_x, m_y et m_value sont de type double?

Oui, désolé de ne pas avoir précisé cela.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Foo
{
  double getX()
  {
    return (m_X);
  }
  double getY()
  {
    return (m_Y);
  }
private:
  double m_X;
  double m_Y;
};

Code:

1
2
3
4
5
6
7
8
9
class Bar
{
  double getValue()
  {
    return (m_value);
  }
private:
  double m_value;
};

11/12/2012, 13h44
ternel

double

Tout est dit.

Tu es, toi aussi, victime de l'approximation flottante.

Certaines corrections anti-erreurs sont applicables sur le cas des variables locales, ce qui n'est pas forcément le cas avec les appels de fonctions.
Ou le contraire

C'est tout de même bizarre. Je viens de faire le test avec le code suivant:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
struct Foo
{
	Foo(double x, double y) : m_X(x), m_Y(y) {}
 
	double getX()
	{
		return (m_X);
	}
 
	double getY()
	{
		return (m_Y);
	}
 
	double m_X, m_Y;
};
 
struct Bar
{
	Bar(double value) : m_value(value) {}
 
	double getValue()
	{
		return (m_value);
	}
 
	double m_value;
};
 
int main(int argc, char* argv[])
{
	Foo foo(2.3, 3.2);
	Bar bar(5.4);
	double result1 = (foo.getX() - bar.getValue()/2 + foo.getY()/2)/foo.getX();
 
	double x = foo.getX();
	double value = bar.getValue();
	double y =  foo.getY();
	double result2 = (x - value/2 + y/2)/x;
 
	getchar();
	return 0;
}

et dans mon test, result1 et result2 sont exactement égaux, avec une visualisation à 17 chiffres après la virgule (je ne sais pas comment en voir plus). Windows 7, visual c++ 2010.

11/12/2012, 13h50
LinuxUser
Je connais le problème de l'approximation flottante (due à la manière de representer les flottants) mais là j'ai du mal à accepter la différence de resultat.

Si je t'avais dit:
Code:

1 2 3 4 5 6 7 8 9 10 11 double x = 3.0; if((1./3.)==(1./x)) { // } else { // approximation flottante } // La OK, je comprends
Mais là tu es entrain de me dire que
Code:

1 2 3 4 5 double x = getX(); if(x != getX()) { // tout est normal: approximation flottante }

r0d:
Essaye une fois avec:
Code:

1 2 3 x = 343.41000000000002501110429875552654; y = 23.70134488207620293565014435444027; value = 33.92;
S'il te plait.

11/12/2012, 14h03
r0d

J'obtiens:
result1 0.98512178574018849
result2 0.98512178574018849

Je ne sais pas comment avoir plus de précision avec vc2010.
Quel est ton environnement de dev (os, compilateur)?
11/12/2012, 14h04
Bousk

Je pense que ça vient du fait que dans le second cas tu passes par des variables intermédiaires. Donc arrondies une fois supplémentaire. Puis le calcul se fait sur les valeurs arrondies, alors que dans le premier il doit pouvoir utiliser des valeurs plus "exacts".
11/12/2012, 14h06
LinuxUser

Code:

Linux xubuntu 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:27:31 UTC 2012 i686 i686 i686 GNU/Linux

Code:

gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2

Je suis tenté de dire : "peut importe l'environnement", car il s'agit du même code executé dans le même envirronement qui produit deux résultats différents selon que je passe par des variables intermédiares ou pas.

r0d:
En reprenant ton code:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include <iostream>
 
struct Foo
{
	Foo(double x, double y) : m_X(x), m_Y(y) {}
 
	double getX()
	{
		return (m_X);
	}
 
	double getY()
	{
		return (m_Y);
	}
 
	double m_X, m_Y;
};
 
struct Bar
{
	Bar(double value) : m_value(value) {}
 
	double getValue()
	{
		return (m_value);
	}
 
	double m_value;
};
 
int main(int argc, char* argv[])
{
    	std::cout.setf(std::ios::fixed, std::ios::floatfield);
	std::cout.precision(32);
	Foo foo(343.41000000000002501110429875552654, 23.70134488207620293565014435444027);
	Bar bar(33.92);
	double result1 = (foo.getX() - bar.getValue()/2 + foo.getY()/2)/foo.getX();
 
	double x = foo.getX();
	double value = bar.getValue();
	double y =  foo.getY();
	double result2 = (x - value/2 + y/2)/x;
 
	std::cout<<"\n\t res1 = "<<result1<<"\n\t res2 = "<<result2<<"\n";
 
	return 0;
}

Voilà ce que j'obtiens:

Code:

1
2
	 res1 = 0.98512178574018849364080097075203
	 res2 = 0.98512178574018838261849850823637

11/12/2012, 14h20
ternel

Juste pour l'expérience, essaie avec des méthodes retournant des "const double&", vu que tu as les membres.
11/12/2012, 14h23
LinuxUser

Citation:

Envoyé par leternel

Juste pour l'expérience, essaie avec des méthodes retournant des "const double&", vu que tu as les membres.

Ca ne change rien, j'obtiens la même différence.
11/12/2012, 14h26
r0d

Citation:

Envoyé par LinuxUser

Je suis tenté de dire : "peut importe l'environnement",

Je demandais ça parce qu'en fait, ta compilation peut être customisée, notamment en ce qui concerne la gestion des flottants. Et je voulais savoir si tu utilisais visual, car dans ce cas j'aurais pu te donner quelques tips. En revanche, je ne connais pas assez gcc pour t'aider sur ce point.
11/12/2012, 14h32
LinuxUser

Citation:

Envoyé par r0d

Je demandais ça parce qu'en fait, ta compilation peut être customisée, notamment en ce qui concerne la gestion des flottants. Et je voulais savoir si tu utilisais visual, car dans ce cas j'aurais pu te donner quelques tips. En revanche, je ne connais pas assez gcc pour t'aider sur ce point.

Maintenant que tu me le dis, en effet j'utilise une option d'optimisation

Code:

gcc -Os

qui optimise la taille.

Mais pour tester ton exemple, j'ai compilé sans option et la différence est tout de même apparue.
11/12/2012, 14h42
ternel

Personnellement, je me base sur le principe de base suivant:
"deux flottants ne sont jamais égaux"

Du coup, je ne me pose pas trop la question.
Le jour où je veux plus d'exactitude … n'est pas encore arrivé.
11/12/2012, 14h46
gbdivers

Sur gcc ubuntu

Citation:

res1 = 0.98512178574018849364080097075203
res2 = 0.98512178574018849364080097075203

Peux tu donner le code asm ? (ajoute -S à la compilation)

@Leternel
C'est un peu strict comme règle. Oui, on doit faire attention en utilisant les réels. Mais 2 calculs identiques doivent donner le même résultat
11/12/2012, 14h51
gbdivers

Au fait, sur quelle machine tu fais tourner ?

En compilant avec -S, j'obtiens à l'execution:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
./main: ligne 1: .file : commande introuvable
./main: ligne 2: .section : commande introuvable
./main: ligne 3: .weak : commande introuvable
./main: ligne 4: .type : commande introuvable
./main: ligne 5: _ZStanSt13_Ios_FmtflagsS_: : commande introuvable
./main: ligne 6: .LFB585: : commande introuvable
./main: ligne 7: .cfi_startproc : commande introuvable
./main: ligne 8: pushl : commande introuvable
./main: ligne 9: .cfi_def_cfa_offset : commande introuvable
./main: ligne 10: .cfi_offset : commande introuvable
./main: ligne 11: movl : commande introuvable
./main: ligne 12: .cfi_def_cfa_register : commande introuvable
./main: ligne 13: Erreur de syntaxe près du symbole inattendu « ( »
./main: ligne 13: `	movl	8(%ebp), %edx'

Ce qui est bizarre, c'est qu'il n'y a pas d'affichage des resultats.

11/12/2012, 14h54
gbdivers

Normal, ça génère le code asm dans le fichier .o et ensuite gcc essaie de continuer la compilation comme si le .o contenait vraiment... un .o :)
Il faut ouvrir le .o avec un éditeur de text
11/12/2012, 15h03
LinuxUser

Citation:

Envoyé par gbdivers

Normal, ça génère le code asm dans le fichier .o et ensuite gcc essaie de continuer la compilation comme si le .o contenait vraiment... un .o :)
Il faut ouvrir le .o avec un éditeur de text

Bizarrement, il fournit pas de .o, donc j'ai compilé sans édition des liens et j'ai obtenu un fichier .s, ça t'interesse (il fait 530 lignes)?
11/12/2012, 15h08
gbdivers

Aucune idée, je sais pas ce qu'il y a dedans. Donne les premières lignes pour voir

Sinon, peux tu aussi donner plus d'infos sur la ligne de commande gcc utilisé ? Tu es sur un machine "standard" (pas embarqué, pas supercalculateur) ?
11/12/2012, 15h11
gbdivers

Teste aussi avec -ffloat-store

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
.file	"main.cpp"
	.section	.text._ZStanSt13_Ios_FmtflagsS_,"axG",@progbits,_ZStanSt13_Ios_FmtflagsS_,comdat
	.weak	_ZStanSt13_Ios_FmtflagsS_
	.type	_ZStanSt13_Ios_FmtflagsS_, @function
_ZStanSt13_Ios_FmtflagsS_:
.LFB585:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	movl	8(%ebp), %edx
	movl	12(%ebp), %eax
	andl	%edx, %eax
	popl	%ebp
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE585:
	.size	_ZStanSt13_Ios_FmtflagsS_, .-_ZStanSt13_Ios_FmtflagsS_
	.section	.text._ZStorSt13_Ios_FmtflagsS_,"axG",@progbits,_ZStorSt13_Ios_FmtflagsS_,comdat
	.weak	_ZStorSt13_Ios_FmtflagsS_
	.type	_ZStorSt13_Ios_FmtflagsS_, @function
_ZStorSt13_Ios_FmtflagsS_:
.LFB586:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	movl	8(%ebp), %edx
	movl	12(%ebp), %eax
	orl	%edx, %eax
	popl	%ebp
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE586:
	.size	_ZStorSt13_Ios_FmtflagsS_, .-_ZStorSt13_Ios_FmtflagsS_
	.section	.text._ZStcoSt13_Ios_Fmtflags,"axG",@progbits,_ZStcoSt13_Ios_Fmtflags,comdat
	.weak	_ZStcoSt13_Ios_Fmtflags
	.type	_ZStcoSt13_Ios_Fmtflags, @function
_ZStcoSt13_Ios_Fmtflags:
.LFB588:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	movl	8(%ebp), %eax
	notl	%eax

Nan je suis sur un PC portable comme on en trouve dans le commmerce, c'est un HP, Core i5, ..., (je vais t'épargner tout le lshw).

11/12/2012, 15h16
LinuxUser

Citation:

Envoyé par gbdivers

Teste aussi avec -ffloat-store

YES, bien vu, j'ai les même résultats avec cette option.

Peux-tu m'expliquer ce qu'il se passe sans cette option?
11/12/2012, 15h20
ternel

mes "quelques optimisations anti erreurs".
Si je me souviens bien, sans l'option, le code ne tente pas de se ramener à un double au sens strict à chaque étape du calcul.
11/12/2012, 15h20
gbdivers

Source : 11.7 Disappointments and Misunderstandings

Citation:

On 68000 and x86 systems, for instance, you can get paradoxical results if you test the precise values of floating point numbers. For example, you can find that a floating point value which is not a NaN is not equal to itself. This results from the fact that the floating point registers hold a few more bits of precision than fit in a double in memory. Compiled code moves values between memory and floating point registers at its convenience, and moving them into memory truncates them.
You can partially avoid this problem by using the -ffloat-store option (see Optimize Options).

En fait, ce qui m'étonne surtout, c'est que normalement, gcc utilise les registres sse pour ce genre de calcul, ce qui n'est pas le cas de ton code. Tu compiles avec quelles options ?

@leternel
En fait, je pense plutôt qu'il passe par les registres x87, qui sont à 80 bits au lieu de 64, d'où la différence. Chez les autres personnes qui ont testé, ça doit passer par les registres SSE qui sont bien à 64 bits
11/12/2012, 15h25
LinuxUser

Citation:

Envoyé par gbdivers

Source : 11.7 Disappointments and Misunderstandings

En fait, ce qui m'étonne surtout, c'est que normalement, gcc utilise les registres sse pour ce genre de calcul, ce qui n'est pas le cas de ton code. Tu compiles avec quelles options ?

Comme je l'ai expliqué tout à l'heure à rOd, sur mon problème je compile avec l'optimisation -Os, mais pour l'exemple simple (Foo, Bar, ...) je compile sans option:

Code:

g++ -o main main.cpp

Et la différence apparait tout de même (sans l'option -ffloat-store).
11/12/2012, 15h31
gbdivers

En fait, il y a plein d'option de compilation par défaut que tu vois pas. Compile avec

Code:

g++ -o main main.cpp -v

Effectivement 8O

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Utilisation des specs internes.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Modèle de thread: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) 
COLLECT_GCC_OPTIONS='-o' 'main' '-v' '-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.7/cc1plus -quiet -v -imultiarch i386-linux-gnu -D_GNU_SOURCE main.cpp -quiet -dumpbase main.cpp -mtune=generic -march=i686 -auxbase main -version -fstack-protector -o /tmp/cc1PKSE6.s
GNU C++ (Ubuntu/Linaro 4.7.2-2ubuntu1) version 4.7.2 (i686-linux-gnu)
	compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
le répertoire « /usr/local/include/i386-linux-gnu » est ignoré car inexistant
le répertoire « /usr/lib/gcc/i686-linux-gnu/4.7/../../../../i686-linux-gnu/include » est ignoré car inexistant
la recherche pour #include "..." débute ici :
la recherche pour #include <...> débute ici:
 /usr/include/c++/4.7
 /usr/include/c++/4.7/i686-linux-gnu
 /usr/include/c++/4.7/backward
 /usr/lib/gcc/i686-linux-gnu/4.7/include
 /usr/local/include
 /usr/lib/gcc/i686-linux-gnu/4.7/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
Fin de la liste de recherche.
GNU C++ (Ubuntu/Linaro 4.7.2-2ubuntu1) version 4.7.2 (i686-linux-gnu)
	compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 35c5a24ca91b342f120e3f1ace87b1cc
COLLECT_GCC_OPTIONS='-o' 'main' '-v' '-shared-libgcc' '-mtune=generic' '-march=i686'
 as -v --32 -o /tmp/cclEQAt2.o /tmp/cc1PKSE6.s
Version de l'assembleur GNU 2.22.90 (i686-linux-gnu) utilisant la version BFD (GNU Binutils for Ubuntu) 2.22.90.20120924
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.7/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'main' '-v' '-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.7/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -z relro -o main /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crt1.o /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crti.o /usr/lib/gcc/i686-linux-gnu/4.7/crtbegin.o -L/usr/lib/gcc/i686-linux-gnu/4.7 -L/usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu -L/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib -L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/i686-linux-gnu/4.7/../../.. /tmp/cclEQAt2.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i686-linux-gnu/4.7/crtend.o /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/crtn.o

11/12/2012, 15h46
gbdivers

Ca commence à sortir de mes compétences :)
Un point de différence avec mon gcc, c'est que je compile en -march=x86-64 alors que tu es en -march=i686. Ta version génère un code compatible avec les anciennes architectures (Pentium IV, III, etc), qui n'avaient pas de SSE. Ca vient peut être de là. Essaies en forçant l'architecture :

Code:

g++ -march=x86-64 -o main main.cpp

Tu peux également utiliser -march=native pour laisser la compilateur choisir l'architecture en fonction du processeur utilisé lors de la compilation (ce qui peut réduire la portabilité du binaire généré)

Source : 3.17.16 Intel 386 and AMD x86-64 Options

Par contre, je ne sais pas d'où vient une telle configuration de gcc. Tu l'as installé comment ?
11/12/2012, 15h49
LinuxUser

Là par contre l'option n'a rien changé.
En même temps c'est normal, j'ai installé un Xubuntu 32bits sur un PC 64bits.

J'ai installé avec synaptic le paquet build-essential.
11/12/2012, 15h58
gbdivers

Ah... je sais pas alors. Mais effectivement, si tu es en 32 bits, je sais pas très bien ce qui est généré et comment le comporte le programme. J'imagine que cela peut se comporter comme si tu utiliser des float et double dans ton programme ? Bref, cela sort de mes compétences à ce niveau :aie: Essaies différentes options de compilation, comme -sse2 ou -m32/-m64
11/12/2012, 16h05
gbdivers

Un peu de lecture, sur le fonctionnement bas niveau des processeurs : http://www.agner.org/optimize/#manuals (niveau avancé)

EDIT : sinon, sans aller aussi loin que leternel, si tu as des contraintes importantes concernant la précision des calculs (plusieurs dizaines de chiffres après la virgule), tu devras te plonger profondement dans le fonctionnement des compilateurs, des processeurs, du bas niveau, etc (à lire, la série d'article d'Alex Darby sur la programmation bas niveau)
11/12/2012, 16h24
ternel

"loin", c'est un grand mot.
J'ai juste subit deux ou trois revers assez vicieux à cause de ce problème, alors je me cantonne à ce que je maîtrise.

Bien sûr qu'on peut avoir une égalité entre double, mais rarement quand on en a besoin.

Du coup, il m'est arrivé de faire des choix d'implémentations pour éviter le double, quitte à perdre un peu de naturel dans les détails. Par exemple, sachant que j'avais le nombre de note, ne pas garder une moyenne mais un total dans la classe, et faire la division si besoin est.
11/12/2012, 16h28
gbdivers

@leternel
Je disais "loin" par rapport à fait que ta phrase signifier "rejeter en masse toutes comparaisons d'égalité sur les réels". Par contre, au final, dans l'attitude, tu as probablement raison de considérer par défaut que rien ne se passe comme attendu. Dans les faits, sauf cas d'application spécifiques, je fais pareil
11/12/2012, 16h32
LinuxUser

En fait, j'aurais du mal à m'extraire de l'utilisation des double, car je démarre une nouvelle implémentation d'un code qui doit produire les même résultats qu'un vieux code (mal foutu).
Et donc, d'après vous, à partir de combien de décimales on peut considérer que c'est un problème d'approximation flottante et non moi qui ai introduit un bias dans les calculs.
Parceque là, c'est à peut près à la 15ème décimale que ça diffère.
Et c'est justement en voulant savoir pourquoi ça différait que je suis tombé sur ce problème de variable intermédiaire.
Je précise qu'il s'agit d'un code de simulation physique (donc beaucoup de calculs flottants :aie:).
11/12/2012, 16h35
r0d

j'avoue qu'il faut être extrêmement prudent lorsqu'on compare des flottants, et je dirais même plus: "c'est comme les pointeurs: à n'utiliser que si on ne peut pas faire autrement".
Et ces problèmes de flottants ne sont pas spécifiques à c++, c'est vrai aussi dans tous les autres langages que je connais (en c#, on arrive même à des résultats différents selon la version du framework utilisé et l'os).
11/12/2012, 16h38
LinuxUser

Oui en effet, mais je l'explique plus haut, je ne fais pas de comparaisons de flottants à proprement parlé :

Code:

if(oldResult==newResult)

Je reproduis la simulation avec les même entrées avec mon code pour le comparer à l'ancien et à la fin je compare "visuellement" les resultats.
Si vous avez une autre méthode de comparaison, je suis preneur.
11/12/2012, 16h39
r0d

Citation:

Envoyé par LinuxUser

Et donc, d'après vous, à partir de combien de décimales on peut considérer que c'est un problème d'approximation flottante et non moi qui ai introduit un bias dans les calculs.

Ca dépend de ton contexte. Si tu fais des calculs de risque (booking) et que tes résultats sont destinés à être récupéré par une macro excel, alors 2 décimales sont suffisantes.
Si tes calculs sont destinés à calculer la trajectoire du satellite qui va être envoyé sur Mars, alors il en faudra plus.
En fait, si la précision est tellement importante, alors il faut opter pour une structure "fait maison" à base d'entiers, ou alors une bibliothèque faite pour.

De façon générale, dans la vraie vie, le delta du bias est le résultat de tests (souvent effectués par les clients si vous voyez ce que je veux dire...). Il n'est presque jamais décidé à priori.

Voir 40 message(s) de cette discussion en une page