🚀 go-pugleaf

"Szyk Cech" <szykcech@spoko.pl> wrote in message 
news:Jk8ME.2$6r.0@fx19.fr7...
>> Przyczyną błędu była różnica odejmowania wynosząca 15.1234e-15
>>
>> Dlaczego konwersja CDbl stringu 31 lub 32.8 dodaje jakieś
>> śmieci do zmiennej double float na 15 miejscu po przecinku??
>> A może odejmowanie stałej 1.8 wprowadza ten błąd?
>>
>> Czy to jest normalne zachowanie się VB6?
>>
>> Czy inne Visuale jak VC++ lub VC# też tak mają?
>
> Weź chłopie ić na studia (ja miałem to nawet na wieczorowych
> 20 lat temu) i się doucz! Zamiast zadawać głupie pytania.

Ale kultury osobistej Cię tam nie nauczyli... szkoda.

> Choć gdybyś dłubał w czymś innym niż VB to byś wiedział
> o problemie (w każdej książce do Asemblera czy C czy C++
> to powinno być).

ha ha :-) No brawo. 

W dniu 2019-06-12 o 14:17, Pszemol pisze:
> Witam, spędziłem wczoraj sporo godzin w biurze na debugowaniu
> kodu napisanego przez naszego kontraktora i w końcu znalazłem buga.
> Przyczyną błędu była różnica odejmowania dwu liczb całkowitych
> wynosząca 15.1234e-15 :-)
> 
> Ale może więcej szczegółów podam:
> 
> Pisząc w Visual Basic 6 gostek porównywał rezultat konwersji CDbl()
> stringu od którego odjął stałą numeryczną 1.8 do lokalnej zmiennej double.
> 
> Czyli mamy kod:
> 
> Sub AlaMaKota(nieważne tutaj argumenty procedury)
> Dim len as Double
> 
> len = CDbl("tekst wydłubany z RS232") - 1.8
> 
> If len <> CDbl("inny tekst wydłubany z RS232) Then
>     zgłoś błąd i kapitulujemy... kaput!
> Else
>     lecimy z testami talej, wsio w pariadkie
> Endif.
> 
> Pierwszy tekst z RS232 był 32.8, drugi 31. 32.8-1.8 = 31.
> Powinno być wszystko ok, bo w matematyce 31 równe jest 31 :-)
> Wynik porównania VB6 był 31 nie jest równe 31 i program
> kapitulował...
> 
> Po zamienieniu testu "if double <> double then" na test
> "if double - double < -0.001 Or double - double > 0.001 then"
> program zaczął pracować normalnie.
> 
> Przyczyną błędu była różnica odejmowania wynosząca 15.1234e-15
> 
> Dlaczego konwersja CDbl stringu 31 lub 32.8 dodaje jakieś
> śmieci do zmiennej double float na 15 miejscu po przecinku??
> A może odejmowanie stałej 1.8 wprowadza ten błąd?
> 
> Czy to jest normalne zachowanie się VB6?
> 
> Czy inne Visuale jak VC++ lub VC# też tak mają?

Kiedy dawno temu (naprawdę dawno) pisałem/modyfikowałem program do pracy 
dyplomowej to w pewnym momencie zaczął się wysypywać z błędem dzielenia 
przez zero. Po dochodzeniu okazało się że pomimo jawnej deklaracji 
double pewne konkretne obliczenia robił na real i w mianowniku pojawiało 
się zero. Żadne jawne deklaracje i wymuszenia typu obliczeń tego nie 
potrafiły zmienić, pomogła dopiero zmiana kompilatora. Sztuczne dodanie 
obliczeń powodowało tylko przesunięcie momentu wywalenia się programu. 
Podobne obliczenia w innym miejscu robił jak należy. A ten drugi 
(właściwie to on był pierwszy tylko z pewnych powodów chciałem użyć 
innego) nie miał w ogóle takich problemów.

Pozdrawiam

DD

> Musialbym sobie przypomniec ... ale przy okazji Assemblera raczej nikt 
> nie poruszal takiego watku.

Pierwsze publikacje o Asemblerze x86 pomijały 386 i koprocesor.
W takiej "Asembler nie tylko dla orłów" Grzegorza Michałka 
(Intersoftland 1997) jest opisany 386 (i 486) z koprocesorem. I co 
prawda nie rozwodzi się tam nad dokładnością obliczeń, ale... Podaje 
jako jeden z możliwych błędów/wyjątków: "Utrata precyzji"/"Błąd 
precyzji" - bit 6 rejestru stanu koprocesora.

> Przy C predzej, ale to gdzies na pograniczu.

Tak czy owak nie powinno się pomijać kilku słów komentarza, podczas 
omawiania typów zmiennoprzecinkowych, na temat potencjalnych problemów 
przy ich stosowaniu.

Użytkownik "AK"  napisał w wiadomości grup 
dyskusyjnych:qe64rf$13b8$2@gioia.aioe.org...
On 2019-06-12 17:27, J.F. wrote:
>> Kto nie uczyl sie Fortranu, ten nie zna zycia :-)

>O przepraszam ! Ja sie uczylem Agolu/Simuli!
>PS: No dobra.. Fortranu też ;)

A na ktorym uczyli o mozliwych cudach numerycznych ? :-)

J.

On 2019-06-17 16:15, J.F. wrote:
> Użytkownik "AK"  napisał w wiadomości grup 
> dyskusyjnych:qe64rf$13b8$2@gioia.aioe.org...
> On 2019-06-12 17:27, J.F. wrote:
>>> Kto nie uczyl sie Fortranu, ten nie zna zycia :-)
> 
>> O przepraszam ! Ja sie uczylem Agolu/Simuli!
>> PS: No dobra.. Fortranu też ;)
> 
> A na ktorym uczyli o mozliwych cudach numerycznych ? :-)

W "moich czasach" na wszystkim...
Na Algolu, na Fortranie, na Metalurgi, na Inzynierii Materialowej
na "Transporcie" itp, itd..

AK

W dniu 2019-06-12 o 17:27, J.F. pisze:

>> Weź chłopie ić na studia (ja miałem to nawet na wieczorowych 20 lat temu) i się doucz! Zamiast
>> zadawać głupie pytania. Choć gdybyś dłubał w czymś innym niż VB to byś wiedział o problemie (w
>> każdej książce do Asemblera czy C czy C++ to powinno być).
> 
> Musialbym sobie przypomniec ... ale przy okazji Assemblera raczej nikt nie poruszal takiego watku.
> Przy C predzej, ale to gdzies na pograniczu.

Na studiach jest (powinien być?) cały przedmiot o nazwie "Arytmetyka maszyn cyfrowych",
gdzie na kilkudziesięciu godzinach wykładów można dokładnie dowiedzieć się, jak są
pamiętane liczby całkowite ze znakiem, bez znaku, zmiennoprzecinkowe, dlaczego i kiedy
występują błędy zaokrągleń itp. Można też dowiedzieć się, że warunek
"jeśli a jest równe b" przy rzeczywistych typach a, b to proszenie się o kłopoty.

Problemy nie zależą od języka programowania. Ułamka dziesiętnego 0.8 nie da się
w przyjętym sposobie zapisu liczb zmiennoprzecinkowych zapisać dokładnie - w układzie
dwójkowym jest to ułamek okresowy, ma nieskończenie wiele znaczących cyfr.
Nie można ich wszystkich pamiętać. Oczywistym rozwiązaniem pozwalającym uniknąć
błędów jest używanie tylko liczb całkowitych. Np. jeśli ma to być jakaś
kwota pieniędzy, należy liczyć w groszach (zawsze całkowitych), a nie złotówkach
i ułamkach złotego.

P.

On Thu, 20 Jun 2019 14:16:12 +0200, Piotrne wrote:
> Np. jeśli ma to być jakaś kwota pieniędzy, należy liczyć w groszach
> (zawsze całkowitych), a nie złotówkach i ułamkach złotego.

Tymczasem akcje Ursusa stoją po 0.797 zł. :)

Mateusz

W dniu 2019-06-20 o 14:16, Piotrne pisze:
> W dniu 2019-06-12 o 17:27, J.F. pisze:
> Oczywistym rozwiązaniem pozwalającym uniknąć
> błędów jest używanie tylko liczb całkowitych. Np. jeśli ma to być jakaś
> kwota pieniędzy, należy liczyć w groszach (zawsze całkowitych), a nie złotówkach
> i ułamkach złotego.
Masz teoretycznie rację ale to jakiego typu zmiennej używasz zależy od 
języka, np w takim Cliperze 5.3
w którym w latach 90 popełniłem kilka programów liczących pieniądze jest 
zmienna INT
ale w praniu wyszło że jest ona typu float :( i z problemem opisanym 
przez Przemol-a musiałem się wtedy już zmierzyć, dodawałem tysięczne 
części grosza na końcu przed samym porównaniem.


-- 
Janusz

W dniu 2019-06-20 o 14:38, Mateusz Viste pisze:

> 
> Tymczasem akcje Ursusa stoją po 0.797 zł. :)
> 

http://wyborcza.biz/Gieldy/1,132329,24492614,gpw-zmiana-dokladnosci-krokow-notowania-akcji-i-na-rynku-terminowym.html

Warszawa, 25.02.2019 (ISBnews) - Giełda Papierów Wartościowych (GPW) w Warszawie zmienia kroki
notowania dla akcji, funduszy typu ETF, kontraktów terminowych na akcje i kursy waluty od 4 marca
2019 r. Kursy tych instrumentów będą określane z dokładnością do czterech miejsc po przecinku
(0,0001 zł), podała Giełda

...czyli jednostką jest tutaj 1/100 grosza.


Czasem praktyczne jest pamiętanie liczb zmiennoprzecinkowych jako ułamków - oddzielnie
licznika i mianownika (typu całkowitego). Tak robi np. VirtualDub (do przetwarzania
filmów) przy zapamiętywaniu parametrów strumienia video.

P.

W dniu 2019-06-20 o 20:39, Janusz pisze:

> Masz teoretycznie rację ale to jakiego typu zmiennej używasz zależy od języka

Można jeszcze użyć typu decimal (np. w C#), który pamięta liczby
w układzie dziesiętnym i nie ma problemów z zaokrągleniami
liczby 0.1. Obliczenia są znacznie wolniejsze niż dla double
(są realizowane programowo, a nie sprzętowo).

P.

Dnia 20 Jun 2019 12:38:12 GMT, Mateusz Viste napisał(a):
> On Thu, 20 Jun 2019 14:16:12 +0200, Piotrne wrote:
>> Np. jeśli ma to być jakaś kwota pieniędzy, należy liczyć w groszach
>> (zawsze całkowitych), a nie złotówkach i ułamkach złotego.
> Tymczasem akcje Ursusa stoją po 0.797 zł. :)

Ciekawe, czy pamietaja na float, double, czy na int w 0.1gr :-)

J.

On 2019-06-20 14:16, Piotrne wrote:
> W dniu 2019-06-12 o 17:27, J.F. pisze:
> 
>>> Weź chłopie ić na studia (ja miałem to nawet na wieczorowych 20 lat temu) i się doucz! Zamiast
>>> zadawać głupie pytania. Choć gdybyś dłubał w czymś innym niż VB to byś wiedział o problemie (w
>>> każdej książce do Asemblera czy C czy C++ to powinno być).
>>
>> Musialbym sobie przypomniec ... ale przy okazji Assemblera raczej nikt nie poruszal takiego watku.
>> Przy C predzej, ale to gdzies na pograniczu.
> 
> Na studiach jest (powinien być?) cały przedmiot o nazwie "Arytmetyka maszyn cyfrowych",
> gdzie na kilkudziesięciu godzinach wykładów można dokładnie dowiedzieć się, jak są
> pamiętane liczby całkowite ze znakiem, bez znaku, zmiennoprzecinkowe, dlaczego i kiedy
> występują błędy zaokrągleń itp. Można też dowiedzieć się, że warunek
> "jeśli a jest równe b" przy rzeczywistych typach a, b to proszenie się o kłopoty.

Swieta racja.

> Problemy nie zależą od języka programowania. Ułamka dziesiętnego 0.8 nie da się
> w przyjętym sposobie zapisu liczb zmiennoprzecinkowych zapisać dokładnie - w układzie
> dwójkowym jest to ułamek okresowy, ma nieskończenie wiele znaczących cyfr.
> Nie można ich wszystkich pamiętać.

J/w.

> Oczywistym rozwiązaniem pozwalającym uniknąć
> błędów jest używanie tylko liczb całkowitych. Np. jeśli ma to być jakaś
> kwota pieniędzy, należy liczyć w groszach (zawsze całkowitych), a nie złotówkach
> i ułamkach złotego.

Nie, gdyz policzenie nawet zwyklej sredniej moze sie okazac problemem.
Moze sie okazac ze obliczenie jej na dwojkowych floatach jest blizsze
rzeczywistosci niz na groszach, bcd czy czymkolwiek innym.

AK

On 2019-06-22 14:47, Piotrne wrote:
> W dniu 2019-06-20 o 20:39, Janusz pisze:
> 
>> Masz teoretycznie rację ale to jakiego typu zmiennej używasz zależy od języka
> 
> Można jeszcze użyć typu decimal (np. w C#), który pamięta liczby
> w układzie dziesiętnym i nie ma problemów z zaokrągleniami
> liczby 0.1. Obliczenia są znacznie wolniejsze niż dla double
> (są realizowane programowo, a nie sprzętowo).

i moga dawac gorsze wyniki od obiczen na floatach
(w dodatku dajac ułudę pewnosci:).

AK

On 2019-06-23 14:57, J.F. wrote:
>> Tymczasem akcje Ursusa stoją po 0.797 zł. :)
> 
> Ciekawe, czy pamietaja na float, double, czy na int w 0.1gr :-)

Nie ma znaczenie jak sa pamietane.
Wazne ja sa prezentowane (i porownywane).

AK

Dnia Tue, 25 Jun 2019 22:09:22 +0200, AK napisał(a):
> On 2019-06-23 14:57, J.F. wrote:
>>> Tymczasem akcje Ursusa stoją po 0.797 zł. :)
>> 
>> Ciekawe, czy pamietaja na float, double, czy na int w 0.1gr :-)
> 
> Nie ma znaczenie jak sa pamietane.
> Wazne ja sa prezentowane (i porownywane).

Ale byloby istotne w kwestii wyzszosci liczb float nad fixed czy
binary nad bcd :-)

J.

W dniu czwartek, 13 czerwca 2019 15:35:14 UTC+2 użytkownik Pszemol napisał:
> "Szyk Cech" <szykcech@spoko.pl> wrote in message 
> news:Jk8ME.2$6r.0@fx19.fr7...
> >> Przyczyną błędu była różnica odejmowania wynosząca 15.1234e-15
> >>
> >> Dlaczego konwersja CDbl stringu 31 lub 32.8 dodaje jakieś
> >> śmieci do zmiennej double float na 15 miejscu po przecinku??
> >> A może odejmowanie stałej 1.8 wprowadza ten błąd?
> >>
> >> Czy to jest normalne zachowanie się VB6?
> >>
> >> Czy inne Visuale jak VC++ lub VC# też tak mają?
> >
> > Weź chłopie ić na studia (ja miałem to nawet na wieczorowych
> > 20 lat temu) i się doucz! Zamiast zadawać głupie pytania.
> 
> Ale kultury osobistej Cię tam nie nauczyli... szkoda.
> 
> > Choć gdybyś dłubał w czymś innym niż VB to byś wiedział
> > o problemie (w każdej książce do Asemblera czy C czy C++
> > to powinno być).
> 
> ha ha :-) No brawo.

szyk ma duzo racji, na pewno gada madrzej niz kolega (przynajmniej w pewnym sensie)

sęk w tym ze jest to problem 
podstawowy, cos jak programistyczne 2+2

tkwienie w tym i spedzanie na tym za duzo czasu 1) skazuje czlowieka na bycie 
noobem duzo czasu pozatym ze ogolnie 2) skazuje czlowieka na bycie noobem

sam swego czasu lubilem tkwic w takich noobich tematach ale pozniej oduczylem sie tego (przynajmniej w sporym stopniu)
i uwazam to chyba za dosyc wazne oduczyc 
sie tego tkwienia w podstawach.. wiaże sie to tez z tym ze jak czlowiek ma troche praktyki zauwaza ze w praktyce zasiek pewnych problemow jest dosyc wąski

a jesli ktos chce sie tego naprawde porzadnie nauczyc to info w necie jest,
sam kiedys czytelem to

http://www.website.masmforum.com/tutorials/fptute/

co prawda dzis na x86/x64 kodu nie kompiluje sie na te instrukcje tylko na skalarne sse ale to wyzej tez mozna przeczytac bo sporo rzeczy (np sam format floata/double) jest analogiczne..