ciekawe na wandbox wszystkie wersje gcc dają DWIE JEDYNKI: http://melpon.org/wandbox/permlink/mMTUvlED6esN7pcR
Dlatego określ dokładnie wersję kompilatora jakiego używasz.
Porównaj swoje F/2 z FLT_EPSILON z modułu cfloat.
F/2 to akurat okolice FLT_EPSILON, wiec wynik nie jest tak oczywisty.
No nie wiesz, bo porównujesz. Ponadto używasz float zamiast double z jakiegoś powodu.
Ale tu nie ma żadnej zagadki. Dokładność float jest skończona, stąd rozbieżność w wynikach. To wszystko.
MarekR22 napisał(a):
No ale sam widzisz, że żadne z naszych build'ów nie daje różnych wyników dla
f1()if2().
No to ja doleję oliwy do ognia. U mnie C++ Builder zwraca właśnie różne wartości. Zaciekawiło mnie to, więc poszedłem o krok dalej (co prawda zmieniłem język na czysty C ale to nie zmienia wyników) i okazało się, że wina leży nie po stronie różnych funkcji, ale sposobów porównania. Porównanie przez zapamiętanie wyniku funkcji przez zmienną daje inny wynik niż porównanie bez użycia zmiennej tymczasowej:
C++ #include <stdio.h>
float F = 1.f / 0x1000000;
float f1()
{
return 1 + F / 2;
}
int main()
{
float ret;
ret = f1();
printf("%d\n",(ret == 1.f));
printf("%d\n",(f1() == 1.f));
return 0;
}</`code>Output jest taki:`1
0
Zatem zobaczmy co siedzi pod spodem w czystym assemblerze:
File1.c.4: float f1()
00401168 55 push ebp
00401169 8BEC mov ebp,esp
File1.c.6: return 1 + F / 2;
0040116B D905A8204000 fld dword ptr [$004020a8]
00401171 D80D80114000 fmul dword ptr [$00401180]
00401177 D80584114000 fadd dword ptr [$00401184]
File1.c.7: }
0040117D 5D pop ebp
0040117E C3 ret
0040117F 0000 add [eax],al
00401181 0000 add [eax],al
00401183 3F aas
00401184 0000 add [eax],al
00401186 803F55 cmp byte ptr [edi],$55
00401189 8BEC mov ebp,esp
0040118B 51 push ecx
File1.c.13: ret = f1();
0040118C E8D7FFFFFF call f1()
00401191 D95DFC fstp dword ptr [ebp-$04]
File1.c.14: printf("%d\n",(ret == 1.f));
00401194 D945FC fld dword ptr [ebp-$04]
00401197 D905E8114000 fld dword ptr [$004011e8]
0040119D D9C9 fxch st(1)
0040119F DAE9 fucompp
004011A1 DFE0 fstsw ax
004011A3 F6C444 test ah,$44
004011A6 0F9BC2 setnp dl
004011A9 83E201 and edx,$01
004011AC 52 push edx
004011AD 68AC204000 push $004020ac
004011B2 E8A1010000 call $00401358
004011B7 83C408 add esp,$08
File1.c.15: printf("%d\n",(f1() == 1.f));
004011BA E8A9FFFFFF call f1()
004011BF D905E8114000 fld dword ptr [$004011e8]
004011C5 D9C9 fxch st(1)
004011C7 DAE9 fucompp
004011C9 DFE0 fstsw ax
004011CB F6C444 test ah,$44
004011CE 0F9BC2 setnp dl
004011D1 83E201 and edx,$01
004011D4 52 push edx
004011D5 68B0204000 push $004020b0
004011DA E879010000 call $00401358
004011DF 83C408 add esp,$08
File1.c.17: return 0;
004011E2 33C0 xor eax,eax
File1.c.18: }
004011E4 59 pop ecx
004011E5 5D pop ebp
004011E6 C3 ret
004011E7 0000 add [eax],al
004011E9 00803FC39090 add [eax-$6f6f3cc1],al
004011EF 90 nop
Linia 14 oraz 15 w C różni się tak naprawdę tylko tymi dwoma instrukcjami:
File1.c.13: ret = f1();
0040118C E8D7FFFFFF call f1()
00401191 D95DFC fstp dword ptr [ebp-$04]
File1.c.14: printf("%d\n",(ret == 1.f));
00401194 D945FC fld dword ptr [ebp-$04]
00401197 D905E8114000 fld dword ptr [$004011e8]
vs
File1.c.15: printf("%d\n",(f1() == 1.f));
004011BA E8A9FFFFFF call f1()
004011BF D905E8114000 fld dword ptr [$004011e8]
No to zdebugujmy sobie. Co tam się kryje pod spodem i w wartościach rejestrów. W obu przypadkach po wywołaniu funkcji f1() w rejestrze ST0 mamy wartość zwracaną przez funkcję równą:
1,00000002980232
Natomiast po załadowaniu do pamięci za pomocą instrukcji fstp do adresu ebp-$04 mamy już 1
Następnie przed porównaniem mamy
Czyli ST(0)=ST(1) W konsekwencji mamy 1 wypisaną.
Idziemy sobie dalej i patrzymy co się dzieje w przypadku gdy mamy bezpośrednie porównanie:
Tutaj po wywołaniu funkcji w ST(0) mamy wartość z dodatkowymi cyframi na końcu
oraz przed samym porównaniem:
Czyli ST(0)!=ST(1) co daje nam 0 podczas wypisywania.
Zatem teraz pozostaje pytanie dlaczego użycie funkcji
0040118C E8D7FFFFFF call f1()
00401191 D95DFC fstp dword ptr [ebp-$04]
Spowodowało zmianę wartości. Aż takim znawcą assemblera nie jestem, więc może ktoś inny wie czy to zwykły błąd podczas pracy na liczbach typu float, czy coś więcej. Chociaż mi się wydaje, że samo przepisanie liczby ze stosu do pamięci nie powinno zmienić wartości.
Fajnie by również było zobaczyć jaki kod wypluwają kompilatory gdzie obie wersje porównania dają takie same wyniki.
Dobra już wiem na czym polega problem.
Kompilator zwraca wartość przez rejestr koprocesora bez względu na typ zwracany, a rejestr ten ma dokładność większą niż double.
Efekt jest taki, że porównując do jedynki wartość zwracaną przez funkcję porównywana jest liczba o większej precyzji i wynik wychodzi na fałsz.
Zapisując jednak liczbę w pamięci następuje konwersja do float i związana z tym utrata precyzji, przez co liczba zostaje zaokrąglona do jedynki. Efekt porównanie daje wynik pozytywny.
Bardzo prosty przykład w C++ obrazujący podobny problem to tego o czym mówi @MarekR22:
#include <iostream>
double a = 0.3;
double b = 0.7;
double c = 0.3*0.7;
int main() {
std::cout << (a * b == c);
}
http://ideone.com/VS0l2B (wynik = 0).
Przez double(x) będę oznaczał "zaokrąglenie matematycznej wartości x do najbliższej wartości floata"
Zmienna a ma wartość double(0.3).
Zmienna b ma wartość double(0.7).
Zmienna c ma wartość double(0.30.7).
I wykonujemy porównanie ab == c, czyli double(0.3) * double(0.7) == double(0.3 * 0.7). Ta druga wartośc jest dokładniejsza, więc porównanie daje wynik negatywny.
(PS. żeby być precyzyjnym, dokładnie porównanie to machine_floating_point(double(0.3) * double(0.7)) == machine_floating_point(double(0.3 * 0.7)), ale wychodzi na to samo - na x86 koprocesor ma 80 bitów, a double ma 64 bity).
MarekR22 napisał(a):
no ale obie funkcje wykonują dokładnie tą samą operację. Jedyna różnica to sposób zwracania wyniku.
Ale jedna jest liczona podczas kompilacji, a druga podczas uruchamiania programu.
x86 ma dwa mechanizmy zmiennoprzecinkowe: FPU i SSE (SSE2).
Mogą one dawać rozbieżne wyniki, choćby z tego powodu, że FPU liczy wewnętrznie na rejestrach 80-bitowych, ma więc większą dokładność niż 64-bitowe SSE2.
Jeśli kompilator używa jednego, a skompilowany program drugiego, to rozbieżności w wynikach są możliwe.
MarekR22 napisał(a):
Kompilator zwraca wartość przez rejestr koprocesora bez względu na typ zwracany, a rejestr ten ma dokładność większą niż double.
Na to nie wpadłem. Jednak wygląda, że to jest rozwiązanie tej zagadki. Swoją drogą żeby nie ten temat nigdy by mi nie przyszło do głowy tak analizować tak trywialną rzecz jaką jest porównanie. Szkoda tylko, że inne kompilatory nie mają takich wyników.