Dlaczego taki output

 #include <iostream>

float F = 1.f / 0x1000000;

float f1()
{
    return 1 + F / 2;
}

void f2( float * ret )
{
    * ret = 1 + F / 2;
}

int main()
{
    std::cout <<( f1() == 1.f ) << '\n';
   
    float ret;
    f2( & ret );
    std::cout <<( ret == 1.f ) << '\n';
}

Dlaczego ten kod pod GCC daje

 0
1

a nie

 1
1

?

To dla tego że ten kod daje:

0
0

zgodnie z oczekiwaniem. http://ideone.com/hLOo5o

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.

Wiem że tak się nie porównuje liczb zmiennoprzecinkowych. Mam GCC 5.1.0

No nie wiesz, bo porównujesz. Ponadto używasz float zamiast double z jakiegoś powodu.

Tym powodem jest to, że kod został znaleziony w internecie jako zagadka. Tam gdzie go znalazłem nikt nie podał odpowiedzi więc pytam się tutaj, bo sam jestem ciekaw.

No ale sam widzisz, że żadne z naszych build'ów nie daje różnych wyników dla f1() i f2().

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() i f2().
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:

#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.