Dlaczego wielokrotne dodawanie 0,1 pozostaje bezstratne?

Wiem, że 0.1liczby dziesiętnej nie można dokładnie przedstawić za pomocą skończonej liczby binarnej ( wyjaśnienie ), więc double n = 0.1straci pewną precyzję i nie będzie dokładnie 0.1. Z drugiej strony 0.5może być reprezentowany właśnie dlatego, że jest 0.5 = 1/2 = 0.1b.

Powiedziawszy, że jest zrozumiałe, 0.1 trzykrotne dodanie nie da dokładnie, 0.3więc wypisuje następujący kod false:

double sum = 0, d = 0.1;
for (int i = 0; i < 3; i++)
    sum += d;
System.out.println(sum == 0.3); // Prints false, OK

Ale jak to się dzieje, że dodanie 0.1 pięciu razy da dokładnie 0.5? Następujący kod drukuje true:

double sum = 0, d = 0.1;
for (int i = 0; i < 5; i++)
    sum += d;
System.out.println(sum == 0.5); // Prints true, WHY?

Jeśli 0.1nie można go dokładnie przedstawić, jak to się dzieje, że dodanie go 5 razy daje dokładnie to, 0.5co można dokładnie przedstawić?

Błąd zaokrąglania nie jest przypadkowy i sposób jego implementacji stara się zminimalizować błąd. Oznacza to, że czasami błąd nie jest widoczny lub nie ma błędu.

Na przykład 0.1nie jest dokładnie 0.1tj., new BigDecimal("0.1") < new BigDecimal(0.1)Ale 0.5jest dokładnie1.0/2

Ten program pokazuje prawdziwe wartości.

BigDecimal _0_1 = new BigDecimal(0.1);
BigDecimal x = _0_1;
for(int i = 1; i <= 10; i ++) {
    System.out.println(i+" x 0.1 is "+x+", as double "+x.doubleValue());
    x = x.add(_0_1);
}

wydruki

0.1000000000000000055511151231257827021181583404541015625, as double 0.1
0.2000000000000000111022302462515654042363166809082031250, as double 0.2
0.3000000000000000166533453693773481063544750213623046875, as double 0.30000000000000004
0.4000000000000000222044604925031308084726333618164062500, as double 0.4
0.5000000000000000277555756156289135105907917022705078125, as double 0.5
0.6000000000000000333066907387546962127089500427246093750, as double 0.6000000000000001
0.7000000000000000388578058618804789148271083831787109375, as double 0.7000000000000001
0.8000000000000000444089209850062616169452667236328125000, as double 0.8
0.9000000000000000499600361081320443190634250640869140625, as double 0.9
1.0000000000000000555111512312578270211815834045410156250, as double 1.0

Uwaga: to 0.3jest nieco wyłączone, ale kiedy dojdziesz do 0.4bitów, musisz przesunąć o jeden w dół, aby zmieścić się w 53-bitowym limicie, a błąd jest odrzucany. Ponownie, skrada się do tyłu o błędach 0.6i 0.7lecz 0.8się 1.0błąd zostanie odrzucony.

Dodanie go 5 razy powinno skumulować błąd, a nie anulować.

Przyczyną wystąpienia błędu jest ograniczona precyzja. tj. 53-bity. Oznacza to, że ponieważ liczba zużywa więcej bitów, gdy staje się większa, bity muszą być odrzucane z końca. Powoduje to zaokrąglanie, które w tym przypadku jest na Twoją korzyść.
Możesz uzyskać odwrotny efekt, gdy uzyskasz mniejszą liczbę, np. 0.1-0.0999=> 1.0000000000000286E-4 I zobaczysz więcej błędów niż wcześniej.

Przykładem tego jest dlaczego w Javie 6 Dlaczego Math.round (0.49999999999999994) zwraca 1 W tym przypadku utrata bitu w obliczeniach skutkuje dużą różnicą w odpowiedzi.

Zakaz przepełnienia, w zmiennoprzecinkowym, x + x + xjest dokładnie zaokrągloną (tj. Najbliższą) liczbą zmiennoprzecinkową do rzeczywistej 3 * x, x + x + x + xwynosi dokładnie 4 * xi x + x + x + x + xponownie jest poprawnie zaokrąglonym przybliżeniem zmiennoprzecinkowym dla 5 * x.

Pierwszy wynik x + x + xwynika z faktu, że x + xjest dokładny. x + x + xjest zatem wynikiem tylko jednego zaokrąglenia.

Drugi wynik jest trudniejszy, jeden z jego wykazów omówiono tutaj (a Stephen Canon nawiązuje do innego dowodu poprzez analizę przypadku na ostatnich 3 cyfrach x). Podsumowując, albo 3 * xjest w tej samej binadzie co 2 * xalbo jest w tej samej binadzie co 4 * x, iw każdym przypadku można wywnioskować, że błąd trzeciego dodawania anuluje błąd drugiego dodawania ( pierwszy dodatek jest dokładny, jak już powiedzieliśmy).

Trzeci wynik, „ x + x + x + x + xjest prawidłowo zaokrąglony”, pochodzi z drugiego w taki sam sposób, w jaki pierwszy wynika z dokładności x + x.

Drugi wynik wyjaśnia, dlaczego 0.1 + 0.1 + 0.1 + 0.1jest to liczba zmiennoprzecinkowa: liczby 0.4wymierne 1/10 i 4/10 są aproksymowane w ten sam sposób, z tym samym błędem względnym, po konwersji na zmiennoprzecinkowe. Te liczby zmiennoprzecinkowe mają stosunek dokładnie 4 między nimi. Pierwszy i trzeci wynik pokazują, że 0.1 + 0.1 + 0.1i 0.1 + 0.1 + 0.1 + 0.1 + 0.1można oczekiwać, że będą miały mniej błędów, niż można by wywnioskować na podstawie naiwnej analizy błędów, ale same w sobie odnoszą się one tylko do wyników odpowiednio 3 * 0.1i 5 * 0.1, co do których można oczekiwać, że będą bliskie, ale niekoniecznie identyczne z 0.3i 0.5.

Jeśli będziesz kontynuować dodawanie 0.1po czwartym dodaniu, w końcu zauważysz błędy zaokrągleń, które powodują, że „ 0.1dodane do siebie n razy” odbiegają n * 0.1od n / 10, a jeszcze bardziej odbiegają od n / 10. Gdybyś miał wykreślić wartości „0,1 dodane do siebie n razy” jako funkcję n, zobaczyłbyś linie o stałym nachyleniu w binadach (gdy tylko wynik n-tego dodania ma wpaść do określonej binady, można oczekiwać, że właściwości dodatku będą podobne do poprzednich dodatków, które dały wynik w tej samej binadzie). W tej samej binadzie błąd będzie się zwiększał lub zmniejszał. Gdybyś spojrzał na sekwencję zboczy od binade do binade, rozpoznałbyś powtarzające się cyfry0.1binarnie przez chwilę. Po tym nastąpiłaby absorpcja i krzywa byłaby płaska.

Systemy zmiennoprzecinkowe wykonują różne magie, w tym mają kilka dodatkowych bitów precyzji do zaokrąglania. Tak więc bardzo mały błąd spowodowany niedokładną reprezentacją 0,1 kończy się zaokrągleniem do 0,5.

Pomyśl o zmiennoprzecinkowych jako świetnym, ale NIESKŁADNYM sposobie przedstawiania liczb. Nie wszystkie możliwe liczby można łatwo przedstawić na komputerze. Liczby nieracjonalne, takie jak PI. Lub jak SQRT (2). (Symboliczne systemy matematyczne mogą je reprezentować, ale powiedziałem „łatwo”).

Wartość zmiennoprzecinkowa może być bardzo bliska, ale nie dokładna. Może być tak blisko, że możesz nawigować do Plutona i oddalać się o kilka milimetrów. Ale nadal nie jest dokładne w sensie matematycznym.

Nie używaj zmiennoprzecinkowych, gdy chcesz być dokładny, a nie przybliżony. Na przykład aplikacje księgowe chcą dokładnie śledzić określoną liczbę groszy na koncie. Liczby całkowite są do tego dobre, ponieważ są dokładne. Podstawowym problemem, na który należy zwrócić uwagę w przypadku liczb całkowitych, jest przepełnienie.

Używanie BigDecimal dla waluty działa dobrze, ponieważ podstawową reprezentacją jest liczba całkowita, choć duża.

Uznając, że liczby zmiennoprzecinkowe są niedokładne, nadal mają wiele zastosowań. Systemy współrzędnych do nawigacji lub współrzędne w systemach graficznych. Wartości astronomiczne. Wartości naukowe. (Prawdopodobnie i tak nie możesz znać dokładnej masy piłki baseballowej do masy elektronu, więc niedokładność nie ma znaczenia).

W przypadku aplikacji liczących (w tym księgowych) użyj liczb całkowitych. Aby policzyć liczbę osób przechodzących przez bramę, użyj wartości int lub long.