C++ Utrata dokładności zmiennoprzecinkowej: 3015/0,00025298219406977296

Question

Problem.

Kompilator Microsoft Visual C++ 2005, 32-bitowy system Windows XP sp3, AMD 64 x 2 procesor.

Kod:

double a = 3015.0; 
double b = 0.00025298219406977296; 
//*((unsigned __int64*)(&a)) == 0x40a78e0000000000 
//*((unsigned __int64*)(&b)) == 0x3f30945640000000 
double f = a/b;//3015/0.00025298219406977296; 

wynikiem obliczeń (czyli "F") jest 11917835,000000000 (((unsigned __int64) (& F)) == 0x4166bb4160000000), chociaż należy +11.917.834,814763514 (tj ((unsigned __int64) (& f)) == 0x4166bb415a128aef).
tj. część ułamkowa jest tracona.
Niestety, potrzebuję części ułamkowej, aby była poprawna.

Pytania:
1) Dlaczego tak się dzieje?
2) Jak mogę rozwiązać problem?

Dodatkowe informacje:
0) Wynik zostanie podjęta bezpośrednio z okna „watch” (nie został wydrukowany, i nie zapomnij ustawić precyzję drukowania). Dostarczyłem również zrzut heksowy zmiennej zmiennoprzecinkowej, więc jestem absolutnie pewien wyniku obliczeń.
1) demontaż f = a/b jest:

fld   qword ptr [a] 
fdiv  qword ptr [b] 
fstp  qword ptr [f] 

2) F = 3015/0,00025298219406977296; Rentowności poprawny wynik (f == 11917834.814763514, ((unsigned __int64) (& f)) == 0x4166bb415a128aef), ale wygląda na to, w tym przypadku wynik jest po prostu obliczone podczas kompilacji:

fld   qword ptr [__real@4166bb415a128aef (828EA0h)] 
fstp  qword ptr [f] 

So , jak mogę naprawić ten problem?

P.S. Znalazłem tymczasowe obejście (potrzebuję tylko częściowego podziału, więc używam po prostu f = fmod (a/b)/b w tej chwili), ale nadal chciałbym wiedzieć, jak rozwiązać ten problem poprawnie - podwójne precyzja ma być 16 cyfr dziesiętnych, więc takie obliczenia nie powinny powodować problemów.

Answer 1

używasz DirectX w programie nigdzie jako że powoduje aby przełączyć w tryb pojedynczej precyzji, chyba że wyraźnie powiedzieć to nie podczas tworzenia urządzenia i spowoduje dokładnie to

Answer 2

Zgaduję, że drukujesz numer bez precyzowania. Spróbuj tego:

#include <iostream> 
#include <iomanip> 

int main() { 
    double a = 3015.0; 
    double b = 0.00025298219406977296; 
    double f = a/b; 

    std::cout << std::fixed << std::setprecision(15) << f << std::endl; 
    return 0; 
} 

produkuje to:

11917834.814763514000000

który wygląda poprawna do mnie. Używam VC++ 2008 zamiast 2005, ale domyślam się, różnica jest w twoim kodzie, nie kompilatorze.

Answer 3

Co ciekawe, jeśli zadeklarujesz zarówno a, jak i b jako pływaki, otrzymasz dokładnie 11917835.000000000. Przypuszczam więc, że jest gdzieś konwersja do pojedynczej precyzji, zarówno w sposobie interpretacji stałych, jak i później w obliczeniach.

Każdy przypadek jest nieco zaskakujący, biorąc pod uwagę, jak prosty jest twój kod. Nie używasz żadnych egzotycznych dyrektyw kompilujących, wymuszających pojedynczą precyzję dla wszystkich liczb zmiennoprzecinkowych?

Edycja: Czy rzeczywiście potwierdziłeś, że skompilowany program generuje niepoprawny wynik? W przeciwnym razie najbardziej prawdopodobnym kandydatem do (błędnej) konwersji pojedynczej precyzji byłby debugger.

Answer 4

Jeśli potrzebujesz dokładnej matematyki, nie używaj zmiennoprzecinkowej.

Zrób sobie przysługę i zdobądź bibliotekę BigNum z racjonalną obsługą numerów.

Answer 5

Czy jesteś pewien, że sprawdzasz wartość f zaraz po instrukcji fstp? Jeśli masz włączone optymalizacje, być może okno zegarka może pokazywać wartość wziętą w jakimś późniejszym punkcie (wydaje się to trochę prawdopodobne, gdy mówisz, że patrzysz na frakcjonalną część f później - czy jakaś instrukcja kończy się maskowaniem jej jakoś?)