Dziwny błąd w Calcu z dokładnością liczb

[golem14]

Mam najnowszego Libre
W calcu mam kolumnę z danymi np. 63,7
W drugiej kolumnie obok wpisałem sobie (ręcznie) przybliżenie w dół co 0,5 w tym wypadku 63,5
W trzeciej kolumnie zrobiłem sobie różnicę tj. =kolumna 1-kolumna 2 co dało tu 0,2
Aby skompaktować widok zrobiłem dwóklik na krawędzi kolumny 1 - zmniejszyła się, dwuklik na kolumnie 2 - zmniejszyła się, dwuklik na kolumnie 3 - powiększyła się!!!! a w komórkach pokazały się niewiarygodne wartości, w podanym przykładzie: 0,200000000000003
Co jest grane? jak odjecie 0,5 od 0,7 może dać wartość inną niż 0,2?
Inne przykłady:
64,7 64,5 0,200000000000003
64 64 0
64,2 64 0,200000000000003
64,7 64,5 0,200000000000003
64,8 64,5 0,299999999999997
64,3 64 0,299999999999997
64,4 64 0,400000000000006
62,8 62,5 0,299999999999997
62,9 62,5 0,399999999999999
63,8 63,5 0,299999999999997
64,2 64 0,200000000000003
63,8 63,5 0,299999999999997
63,4 63 0,399999999999999
Czy to błąd czy to "feature"?

[Vakarian]

Próbowałem odtworzyć to "zdarzenie" u siebie, ale nie dało rady, jednakże gdy ustawiłem we właściwościach komórki większą liczbę miejsc dziesiętnych, to wynik był taki jak u Ciebie, czyli z 3 na piętnastym miejscu po przecinku. Morał? Calc nie jest "aż tak" dokładny w obliczeniach, a przynajmniej można tak wnioskować. Zawsze możesz ustawić wspomnianą już liczbę miejsc dziesiętnych, np. dwa. Jeżeli nie potrzebujesz obliczeń z tak dużą precyzją, to rozwiąże Twój problem. Ponoć czego oczy nie widzą, tego sercu nie żal.

[golem14]

Zastanawiam się czy to błąd do zgłoszenia developerom.
Ja nic w ustawieniach nie zmieniałem a więc standardowo dostaje błędy w arkuszu. Jak mogę ufać programowi, który myli się na 12 miejscu po przecinku? To, że błędu nie widać przy ograniczonej precyzji wyświetlania, nie oznacza, że go nie ma - a matematyka jest matematyką... A-B powinno dawać C a nie C,x.

[Jan_J]

Nie ma w tym nic dziwnego. "Liczby" w arkuszu nie są liczbami, tylko danymi binarnymi.

Calc używa w obliczeniach typu zmiennopozycyjnego double, mającego (w dużym uproszczeniu) możliwość pamiętania 16 cyfr dziesiętnych oraz całkowitego czynnika skalującego, sterującego położeniem przecinka.

Na dodatek, liczby pamiętane są w systemie dwójkowym a nie dziesiętnym, wobec czego liczby takie jak 0,1 i 0,2 nie mogą być pamiętane w sposób dokładny, gdyż mają nieskończone rozwinięcia dwójkowe.

Te dwa fakty powodują, że wyniki działań czasem bywają inne niż wyniki "prawdziwych" działań na "prawdziwych" liczbach. Ten "błąd" jest niezbywalną cechą rachunków zmiennopozycyjnych. Mają go praktycznie wszystkie systemy liczące w ten sposób, m.in. C, Python, Java, Calc, Excel i wiele innych.

W zasadzie błąd ten pochodzi z niższego poziomu obliczeń: z realizacji sprzętowych, wbudowanych w procesor komputera.

Dodam jeszcze, że arkusze kalkulacyjne nie rozpoznają liczb całkowitych jako osobnego typu danych, wobec czego mogą dawać wyniki niepoprawne także w przypadku operowania na dużych liczbach całkowitych. Np. =123456789101112131415 + 1 daje 123456789101112000000. Nie ma możliwości pamiętania więcej niż 16 cyfr w liczbie, a dodatkowe zera na końcu są uzyskane przez czynnik skalujący.

[Vakarian]

Jan_J rozwinął moje "Calc nie jest "aż tak" dokładny w obliczeniach" w taki sposób, że już chyba dokładnie wiadomo, co jest przyczyną takiego zachowania. Wychodzi na to, że jeżeli ktoś działa na liczbach ogromnych lub z dużą ilością miejsc po przecinku, nie ma czego w Calcu szukać. Dobrze, że mi z reguły wystarczają dwa miejsca po przecinku.

[Jan_J]

nie ma czego w Calcu szukać

Ani w Calcu, ani w Excelu. Chyba że użyjemy emulacji obliczeń stałopozycyjnych, tzn. opcji "Dokładność jak pokazano", która eliminuje niektóre z wyszczególnionych problemów, ale za to stwarza inne.
A także, jeśli zamierza korzystać ze standardowych wbudowanych w systemy typów danych, a nie ze specjalistycznych bibliotek , to ani w Matlabie, ani w C, ani w Javie, ani w Perlu, ani w Pythonie, ani w PHP, ani w ...