NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Precyzja liczb zmiennoprzecinkowych w VB6 - dlaczego wynik 31 nie równa się 31?
Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next
Piotr Wyderski
Guest
Guest
Wed Jun 19, 2019 7:17 am
AK wrote:
Quote:
Uj nie mam pojecia co to jest 
https://en.wikipedia.org/wiki/Cascaded_integrator%E2%80%93comb_filter
Genialnie "wchodzą" w FPGA i inny sprzęt, w software nieco słabiej.
Pół świata na tym stoi, na 100% masz np. w telefonie.
Pozdrawiam, Piotr
J.F.
Guest
Guest
Wed Jun 19, 2019 9:35 am
Użytkownik "AK" napisał w wiadomości grup
dyskusyjnych:qecl7l$1qds$1@gioia.aioe.org...
On 2019-06-17 16:20, J.F. wrote:
Quote:
Czy inne Visuale jak VC++ lub VC# też tak mają?
To jest problem procesora z FP IEEEcostam.
Wcale nie. To jest problem jak najbardziej ogolny.
Ogolny, ale te formaty, co wewnetrznie uzywaja liczb z mantysą
binarna, to maja problem z liczbami dziesietnymi.
A te (a byly/sa takie) ktore uzywaja wewnetrznie systemu dziesietnego
maja rownie powazne problemy z danymi binarnymi.
Zaden argument.
To jest problem procesora z FP IEEEcostam.
Wcale nie. To jest problem jak najbardziej ogolny.
Ogolny, ale te formaty, co wewnetrznie uzywaja liczb z mantysą
binarna, to maja problem z liczbami dziesietnymi.
A te (a byly/sa takie) ktore uzywaja wewnetrznie systemu dziesietnego
maja rownie powazne problemy z danymi binarnymi.
Zaden argument.
No ale liczby dziesietne ludzie uzywaja nagminnie, a liczb binarnych
zmiennoprzecinkowych ... to nawet programisci nie uzywaja :-)
Zdarzylo Ci sie kiedys okreslic, ze to by bylo dobrze przemnozyc
przez
11.01101
?
Quote:
PS: Kto k.. skrosowal ten watek?!
Nie ja.
J.
J.F.
Guest
Guest
Wed Jun 19, 2019 9:45 am
Użytkownik "AK" napisał w wiadomości grup
dyskusyjnych:qeckl4$1nvk$1@gioia.aioe.org...
On 2019-06-17 16:09, J.F. wrote:
Quote:
Dzisiejsze koprocesory ciagle maja ten sam format liczby double,
ktory powoduje te błędy.
Taaa? A zauwazyl Ty ze "przy okazji" posiadaja jeden z formatow
dluzszy
niz najdluzszy int (czyli 80bit)?
Czyli moze liczyc w wiekszym zakresie
ktory powoduje te błędy.
Taaa? A zauwazyl Ty ze "przy okazji" posiadaja jeden z formatow
dluzszy
niz najdluzszy int (czyli 80bit)?
Czyli moze liczyc w wiekszym zakresie
Bez znaczenia - problem ciagle ten sam.
Nawiasem mowiac - czy mi sie wydaje, czy ten format 80-bit jest po
cichutku wycofywany ?
Quote:
Wczorajsze koprocesory mialy formaty BCD, ktore akurat pieniadze
liczyly dokladnie, czy dzisiejsze maja to juz nie wiem.
Kolejny mit, ze BD jest "zbawieniem na cale zlo".
liczyly dokladnie, czy dzisiejsze maja to juz nie wiem.
Kolejny mit, ze BD jest "zbawieniem na cale zlo".
Nie, ale czesto ulatwia.
Quote:
PS: "My" akurat w defBank-u stosowalismy zwykle double i jakos
Assecco
sie z tego powodu do dzis nie przekrecilo
Assecco
sie z tego powodu do dzis nie przekrecilo
A kto zgarnial "cwierccentowki Dextera" ? :-)
Ze wspomnien starszego informatyka ... bankowego.
"Fortran, co to za g* jest. Klient ma na koncie 25.60, przychodzi mu
74.40,
i na koncie ma 99.999996
Przeszlismy na podwojna precyzje. To teraz ma
99.999999999954
"
J.
Mateusz Viste
Guest
Guest
Wed Jun 19, 2019 11:40 am
On Wed, 19 Jun 2019 11:45:24 +0200, J.F. wrote:
Quote:
Ze wspomnien starszego informatyka ... bankowego.
"Fortran, co to za g* jest. Klient ma na koncie 25.60, przychodzi mu
74.40,
i na koncie ma 99.999996 Przeszlismy na podwojna precyzje. To teraz ma
99.999999999954 "
"Fortran, co to za g* jest. Klient ma na koncie 25.60, przychodzi mu
74.40,
i na koncie ma 99.999996 Przeszlismy na podwojna precyzje. To teraz ma
99.999999999954 "
Dobre :)
A na problem - mimo że powszechnie znany - jednak ciągle nadziewają się
nowi. Dziwne, że w banku (wydawałoby się, poważnej instytucji) w to
wpadają.
Ciekawostka - GnuCash z tego powodu wiele lat temu zrezygnował z float na
rzecz stałego przecinka: http://www.gnucash.org/docs/v1.6/C/t7204.html
Mateusz
KLoSS
Guest
Guest
Wed Jun 19, 2019 7:51 pm
W dniu 19.06.2019 o 13:40, Mateusz Viste pisze:
Quote:
On Wed, 19 Jun 2019 11:45:24 +0200, J.F. wrote:
Ze wspomnien starszego informatyka ... bankowego.
"Fortran, co to za g* jest. Klient ma na koncie 25.60, przychodzi mu
74.40,
i na koncie ma 99.999996 Przeszlismy na podwojna precyzje. To teraz ma
99.999999999954 "
Dobre :)
A na problem - mimo że powszechnie znany - jednak ciągle nadziewają się
nowi. Dziwne, że w banku (wydawałoby się, poważnej instytucji) w to
wpadają.
Mateusz
Ze wspomnien starszego informatyka ... bankowego.
"Fortran, co to za g* jest. Klient ma na koncie 25.60, przychodzi mu
74.40,
i na koncie ma 99.999996 Przeszlismy na podwojna precyzje. To teraz ma
99.999999999954 "
Dobre :)
A na problem - mimo że powszechnie znany - jednak ciągle nadziewają się
nowi. Dziwne, że w banku (wydawałoby się, poważnej instytucji) w to
wpadają.
Mateusz
Nowi jak nowi, ale żeby wojsko... I niestety były ofiary.
http://www-users.math.umn.edu/~arnold//disasters/patriot.html
KLoSS
Pszemol
Guest
Guest
Thu Jun 20, 2019 12:52 am
"AK" <nobody@nowhere.net> wrote in message
news:qe665k$18po$2@gioia.aioe.org...
Quote:
On 2019-06-13 15:37, Pszemol wrote:
"Mateusz Viste" <mateusz@nie.pamietam> wrote in message
news:5d00f035$0$15194$426a74cc@news.free.fr...
On Wed, 12 Jun 2019 07:17:45 -0500, Pszemol wrote:
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.
Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
Faktem jest, że gdy zmienne nie skaczą dynamicznie od e-15 do e+15 to
warto znaleźć zakres wariacji mierzonej zmiennej, oczekwianą dokładność
i zamiast na float operować na long integer * 10000 na przykład...
1. ile masz takich przypadkow w zyciu (owszem, fraktale).
"Mateusz Viste" <mateusz@nie.pamietam> wrote in message
news:5d00f035$0$15194$426a74cc@news.free.fr...
On Wed, 12 Jun 2019 07:17:45 -0500, Pszemol wrote:
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.
Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
Faktem jest, że gdy zmienne nie skaczą dynamicznie od e-15 do e+15 to
warto znaleźć zakres wariacji mierzonej zmiennej, oczekwianą dokładność
i zamiast na float operować na long integer * 10000 na przykład...
1. ile masz takich przypadkow w zyciu (owszem, fraktale).
W konkretnych zastosowaniach przemysłowych? Embedded?
Bardzo dużo.
Quote:
2. przy dzisiejszych koprocesorach ? Na pewno warto ?
/Kiedys zdecydowanie tak, wiec absolutnie podejscia nie potępiam/.
/Kiedys zdecydowanie tak, wiec absolutnie podejscia nie potępiam/.
A co ma koprocesor tutaj do rzeczy?
Piotrne
Guest
Guest
Thu Jun 20, 2019 12:16 pm
W dniu 2019-06-12 o 17:27, J.F. pisze:
Quote:
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.
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.
Mateusz Viste
Guest
Guest
Thu Jun 20, 2019 12:38 pm
On Thu, 20 Jun 2019 14:16:12 +0200, Piotrne wrote:
Quote:
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.
(zawsze całkowitych), a nie złotówkach i ułamkach złotego.
Tymczasem akcje Ursusa stoją po 0.797 zł. :)
Mateusz
JarosĹaw SokoĹowski
Guest
Guest
Thu Jun 20, 2019 2:10 pm
Pan Mateusz Viste napisał:
Quote:
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ł.
(zawsze całkowitych), a nie złotówkach i ułamkach złotego.
Tymczasem akcje Ursusa stoją po 0.797 zł.
Zdaje się, że na słowackich stacjach benzynowych ceny paliwa podawane
są z taką dokładnością (w euro).
--
Jarek
Mateusz Viste
Guest
Guest
Thu Jun 20, 2019 3:01 pm
On Thu, 20 Jun 2019 16:10:54 +0200, Jarosław Sokołowski wrote:
Quote:
Pan Mateusz Viste napisał:
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ł. :)
Zdaje się, że na słowackich stacjach benzynowych ceny paliwa podawane są
z taką dokładnością (w euro).
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ł. :)
Zdaje się, że na słowackich stacjach benzynowych ceny paliwa podawane są
z taką dokładnością (w euro).
We Francji także, i ten przykład pierwszy przyszedł mi do głowy, ale
uznałem go za chybiony - wszak Piotrne specyficznie pisał o atomizmie
grosza, a nie centa.
Mateusz
JarosĹaw SokoĹowski
Guest
Guest
Thu Jun 20, 2019 3:26 pm
Pan Mateusz Viste napisał:
Quote:
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ł. :)
Zdaje się, że na słowackich stacjach benzynowych ceny paliwa podawane
są z taką dokładnością (w euro).
We Francji także, i ten przykład pierwszy przyszedł mi do głowy, ale
uznałem go za chybiony - wszak Piotrne specyficznie pisał o atomizmie
grosza, a nie centa.
(zawsze całkowitych), a nie złotówkach i ułamkach złotego.
Tymczasem akcje Ursusa stoją po 0.797 zł. :)
Zdaje się, że na słowackich stacjach benzynowych ceny paliwa podawane
są z taką dokładnością (w euro).
We Francji także, i ten przykład pierwszy przyszedł mi do głowy, ale
uznałem go za chybiony - wszak Piotrne specyficznie pisał o atomizmie
grosza, a nie centa.
Ponadto w przypadku paliw, niejako z definicji, mamy do czynienia ze
zmienną typu float.
--
Jarek
Janusz
Guest
Guest
Thu Jun 20, 2019 6:39 pm
W dniu 2019-06-20 o 14:16, Piotrne pisze:
Quote:
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
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
Piotrne
Guest
Guest
Sat Jun 22, 2019 11:36 am
W dniu 2019-06-20 o 14:38, Mateusz Viste pisze:
Quote:
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.
Piotrne
Guest
Guest
Sat Jun 22, 2019 12:47 pm
W dniu 2019-06-20 o 20:39, Janusz pisze:
Quote:
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.
J.F.
Guest
Guest
Sun Jun 23, 2019 12:57 pm
Dnia 20 Jun 2019 12:38:12 GMT, Mateusz Viste napisał(a):
Quote:
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ł.
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.
elektroda NewsGroups Forum Index - Elektronika Polska - Precyzja liczb zmiennoprzecinkowych w VB6 - dlaczego wynik 31 nie równa się 31?