🚀 go-pugleaf

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.

Obowiązkowa lektura na wieczór:
http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf

Mateusz

On Wednesday, June 12, 2019 at 2:17:44 PM UTC+2, Pszemol wrote:
> 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 :-)

Ale nie działasz na liczbach rzeczywistych, ale na reprezentacji
zmiennoprzecinkowej. 
Wszytkie trzy liczby tak naprawde mają wartość tylko zblizoną
do tych napisanych. 

> 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.

Używaj funkcji abs, to samo, a czytelniej. 

Tak, to jest poprawne rozwiązanie. 

> 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ą?

W sumei to pierwsz rzecz, jakiej człowiek sie dowiaduja na jakimkolwiek
poważniejsyzm kursie dotykającym zmiennego przecinka. Ze szczegolnym
uwzlgędnieniem
"Nie wykonuj porównania == i <> na liczbach zmiennoprzecinkowych"


A jaka przyczyna? To przy okazji opisują.

Zerknij na wiki, jak wyglada liczba zmiennoprzecinkowa.

2^coś *1.mantysa.

1/2 tak zapiszesz, ale 1/3 nie. 1/10 też nie.
Zerknij tutaj, 
https://www.h-schmidt.net/FloatConverter/IEEE754.html 
Liczy na single, ale zasada ta sama.
wpisując 1.8 tak naprawdę trzymasz najbliższa
reprezentaowalną liczbę, 1.7999999523162841796875
Podobnie 32.8. 
31 jest reprezentowane dokładnie. 

Teraz każda podstawowa operacja arytmetyczna biorąca argumenty
a i b (oznaczamy fl(a) i fl(b) jako wartośći reprezentowane) liczy 
fl(a) (działanie) fl(b) dokładnie, a potem zapisuje jako najbliższa
reprezentowalna wartość. 

W ogolności 
fl(a+b) = (fl(a)+fl(b))(1+eps), gdize ten epsylon to dokłądność
reprezentacji. 



pzdr
bartekltg 

In pl.misc.elektronika Mateusz Viste <mateusz@nie.pamietam> wrote:

> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.

Nie szedłbym tak daleko. Oczywiście używają ale wiedzą też, jakie są ich 
ograniczenia i jak je porównywać.

-- 
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

W dniu 12.06.2019 o 14:29, Mateusz Viste pisze:

> 
> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
> 
> Obowiązkowa lektura na wieczór:
> http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf
> 

Nie ma co przesadzać, liczby zmiennoprzecinkowe po to powstały, żeby je
używać. Trzeba tylko porównywać je zakładając pewną dopuszczalną
tolerancję.


-- 
Cezary Grądys
czarekgr@wa.onet.pl

"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...

> Obowiązkowa lektura na wieczór:
> http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf

Dzięki za linka, zapoznam się w wolnym czasie. 

"bartekltg" <bartekltg@gmail.com> wrote in message 
news:a843c978-5bcc-4a8a-97bd-67b77c7defe7@googlegroups.com...
> Używaj funkcji abs, to samo, a czytelniej.

Słuszna uwaga - dzięki.

> W sumei to pierwsz rzecz, jakiej człowiek sie dowiaduja na jakimkolwiek
> poważniejsyzm kursie dotykającym zmiennego przecinka. Ze szczegolnym
> uwzlgędnieniem
> "Nie wykonuj porównania == i <> na liczbach zmiennoprzecinkowych"

I tyle mi zostało w głowie bo właśnie to <> mi się rzuciło w oczy
i zacząłem tam badać. Ale już wyleciała z głowy interpretacja "dlaczego".

> A jaka przyczyna? To przy okazji opisują.
>
> Zerknij na wiki, jak wyglada liczba zmiennoprzecinkowa.
>
> 2^coś *1.mantysa.
>
> 1/2 tak zapiszesz, ale 1/3 nie. 1/10 też nie.
> Zerknij tutaj,
> https://www.h-schmidt.net/FloatConverter/IEEE754.html
> Liczy na single, ale zasada ta sama.
> wpisując 1.8 tak naprawdę trzymasz najbliższa
> reprezentaowalną liczbę, 1.7999999523162841796875
> Podobnie 32.8.
> 31 jest reprezentowane dokładnie.
>
> Teraz każda podstawowa operacja arytmetyczna biorąca argumenty
> a i b (oznaczamy fl(a) i fl(b) jako wartośći reprezentowane) liczy
> fl(a) (działanie) fl(b) dokładnie, a potem zapisuje jako najbliższa
> reprezentowalna wartość.
>
> W ogolności
> fl(a+b) = (fl(a)+fl(b))(1+eps), gdize ten epsylon to dokłądność
> reprezentacji.

Dzięki.
Wartościowe odświeżenie sobie w głowie ważnego detalu
z dziedziny programowania! 

On Thursday, June 13, 2019 at 3:37:52 PM UTC+2, 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.

Pieprzenie. No, czyba, że programowanie = frontend.

> 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...

Co najwyżęj, jak obracasz walutą. Standard to chyba 1/10000 jednostki
(złotówki, dolara...).

BTW, long int to raz 32, raz 64 bity. A teoretycznie może mieć i inną wartość;-) 

pzdr
bartekltg

On Wednesday, June 12, 2019 at 3:07:25 PM UTC+2, bartekltg wrote:
> On Wednesday, June 12, 2019 at 2:17:44 PM UTC+2, Pszemol wrote:
> > 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 :-)
> 
> Ale nie działasz na liczbach rzeczywistych, ale na reprezentacji
> zmiennoprzecinkowej. 
> Wszytkie trzy liczby tak naprawde mają wartość tylko zblizoną
> do tych napisanych. 
> 
> > 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.
> 
> Używaj funkcji abs, to samo, a czytelniej. 
> 
> Tak, to jest poprawne rozwiązanie. 
> 
> > 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ą?
> 
> W sumei to pierwsz rzecz, jakiej człowiek sie dowiaduja na jakimkolwiek
> poważniejsyzm kursie dotykającym zmiennego przecinka. Ze szczegolnym
> uwzlgędnieniem
> "Nie wykonuj porównania == i <> na liczbach zmiennoprzecinkowych"
> 
> 
> A jaka przyczyna? To przy okazji opisują.
> 
> Zerknij na wiki, jak wyglada liczba zmiennoprzecinkowa.
> 
> 2^coś *1.mantysa.
> 
> 1/2 tak zapiszesz, ale 1/3 nie. 1/10 też nie.
> Zerknij tutaj, 
> https://www.h-schmidt.net/FloatConverter/IEEE754.html 
> Liczy na single, ale zasada ta sama.
> wpisując 1.8 tak naprawdę trzymasz najbliższa
> reprezentaowalną liczbę, 1.7999999523162841796875
> Podobnie 32.8. 
> 31 jest reprezentowane dokładnie. 
> 
> Teraz każda podstawowa operacja arytmetyczna biorąca argumenty
> a i b (oznaczamy fl(a) i fl(b) jako wartośći reprezentowane) liczy 
> fl(a) (działanie) fl(b) dokładnie, a potem zapisuje jako najbliższa
> reprezentowalna wartość. 
 
> W ogolności 
> fl(a+b) = (fl(a)+fl(b))(1+eps), gdize ten epsylon to dokłądność
> reprezentacji. 

Lepiej by było, jakbym napisał, że eps jest rzędu wielkośći reprezentacji.
Może być 0, może być jak dokładność v, dodatnia lub ujemna. Wzorkiem:
abs( eps ) < v.




 pzdr
 bartekltg

On 2019-06-13 23:22, bartekltg wrote:
[...]
> BTW, long int to raz 32, raz 64 bity. A teoretycznie może mieć i inną wartość;-) 
A czasami zwykły int to raz 16, a raz 32 bity. :-) W zależności od
ustawień kompilatora – vide MCU z rodziny H8/300H, H8S i pokrewne.

On Thu, 13 Jun 2019 14:22:06 -0700, bartekltg wrote:
> On Thursday, June 13, 2019 at 3:37:52 PM UTC+2, 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.
> 
> Pieprzenie. No, czyba, że programowanie = frontend.
> 
>> 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...
> 
> Co najwyżęj, jak obracasz walutą. Standard to chyba 1/10000 jednostki
> (złotówki, dolara...).
> 
> BTW, long int to raz 32, raz 64 bity. A teoretycznie może mieć i inną
> wartość;-)

Prawdziwi programiści zakładają, że typ danych jest najwęższy możliwy: 
int=16, long=32, long long=64. A jeśli chcą czegoś konkretnego to znają 
stdint.h i potrafią korzystać z uint32_t i jemu podobnych.

Mateusz

On 2019-06-12 16:54, Cezary Grądys wrote:
> W dniu 12.06.2019 o 14:29, Mateusz Viste pisze:
> 
>>
>> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
>>
>> Obowiązkowa lektura na wieczór:
>> http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf
>>
> 
> Nie ma co przesadzać, liczby zmiennoprzecinkowe po to powstały, żeby je
> używać. Trzeba tylko porównywać je zakładając pewną dopuszczalną
> tolerancję.

No dooobra.
Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
(Ba! KANON!), bo przy takiej wiedzy "mlodego pokolenia" znow
zaczną nam przychodzic ponaglenia o pilną zapłatę 0.00PLN.

a == b  ->   fabs(a - b) <= EPS
a != b  ->   fabs(a - b) > EPS
a < b   ->   (a - b) < -EPS
a > b   ->   (a - b) > EPS
a <= b  ->   (a - b) <= EPS
a >= b  ->   (a - b) >= -EPS

PS: Oczywiscie EPS moze miec rozna nature i wartosci zaleznie np.
od domeny (numeryka, finanse itp). Np. Moze byc bezwzgledne, ale
czesto bywa wzgledne, a w numeryce to juz w ogole...
Np. w optymalizacji moze byc dynamiczne (np zalezne nie tylko
od wartosci ale i innych cech funkcji, np gradientu) i sztuka
sama w sobie jest je dobierac/szacowac np w slabo zbieznych algorytmach
czy gdy np. funcja jest baaardzo stroma. No ale to juz zupelnie inna
"para kaloszy".

PS0: Oczywiscie w niektorych "higienicznych" przypadkach (np. szukanie
wartosci maksymalnej) dopuszczalne jest zwykłę >, ale to nie
łamie/przeczy w/w regułom.

AK

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).
2. przy dzisiejszych koprocesorach ? Na pewno warto ?
/Kiedys zdecydowanie tak, wiec absolutnie podejscia nie potępiam/.

AK

On 2019-06-13 23:22, bartekltg wrote:

>>> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
> 
> Pieprzenie. No, czyba, że programowanie = frontend.

100% zgody :) Uzyte slowo tez wlasciwe/adekwatne ;)

AK

On 2019-06-13 23:25, bartekltg wrote:
>> W ogolności
>> fl(a+b) = (fl(a)+fl(b))(1+eps), gdize ten epsylon to dokłądność
>> reprezentacji.
> 
> Lepiej by było, jakbym napisał, że eps jest rzędu wielkośći reprezentacji.

O tak. To bardziej adekwatne.

AK

On 2019-06-14 08:19, Mateusz Viste wrote:

> Prawdziwi programiści zakładają, że typ danych jest najwęższy możliwy:
> int=16, long=32, long long=64.

Niestety to duzy blad :(

AK

On Sunday, June 16, 2019 at 9:40:44 PM UTC+2, AK wrote:
> On 2019-06-12 16:54, Cezary Grądys wrote:
> > W dniu 12.06.2019 o 14:29, Mateusz Viste pisze:
> > 
> >>
> >> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
> >>
> >> Obowiązkowa lektura na wieczór:
> >> http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf
> >>
> > 
> > Nie ma co przesadzać, liczby zmiennoprzecinkowe po to powstały, żeby je
> > używać. Trzeba tylko porównywać je zakładając pewną dopuszczalną
> > tolerancję.
> 
> No dooobra.
> Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
> (Ba! KANON!), bo przy takiej wiedzy "mlodego pokolenia" znow
> zaczną nam przychodzic ponaglenia o pilną zapłatę 0.00PLN.
> 
> a == b  ->   fabs(a - b) <= EPS
> a != b  ->   fabs(a - b) > EPS

Zgoda.

> a < b   ->   (a - b) < -EPS
> a > b   ->   (a - b) > EPS
> a <= b  ->   (a - b) <= EPS
> a >= b  ->   (a - b) >= -EPS

A to po co? 
Jeśli chemy rozróżnić trzy przypadki,
'wystarczająco równe', większe, mnijesze,
to OK. Ale bardzo często nierórności tego typu
testuje się do rozdielenia mniejszych i większych,
wtedy to ma mały sens.

Np mam algorytm, sprawdzam oszacowanie na błąd:

while (est_error > tol )...

mieszanie tu eps nic jakościoweo nie zmieni. 

pzdr
bartekltg

On Sun, 16 Jun 2019 21:53:24 +0200, AK wrote:
> On 2019-06-14 08:19, Mateusz Viste wrote:
>> Prawdziwi programiści zakładają, że typ danych jest najwęższy możliwy:
>> int=16, long=32, long long=64.
> 
> Niestety to duzy blad :(

Jakieś argumenty?

Mateusz

On Sun, 16 Jun 2019 21:43:50 +0200, AK wrote:
> 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).
> 2. przy dzisiejszych koprocesorach ? Na pewno warto ?
> /Kiedys zdecydowanie tak, wiec absolutnie podejscia nie potępiam/.

Koprocesory nie mają tu nic do rzeczy - na 386SX też dało się korzystać z 
float, mimo braku FPU. Oczywiście kosztem wydajności, ale nie o tym 
przecież mówimy.

Float/Double ze swojej natury nie zapewnia dokładności i dlatego to je 
skreśla w większości zastosowań w których ludzie intuicyjnie z nich 
korzystają (głównie: liczenie pieniędzy). Fakt - są sytuacje kiedy float 
*może* być dobrym rozwiązaniem: fraktale, przetwarzanie grafiki lub 
dźwięku i generalnie wszystko, co nie wymaga ścisłego wyniku. Ale to - 
przynajmniej z mojego punktu widzenia - specjalistyczne wyjątki.

Mateusz

AK wrote:

> No dooobra.
> Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
> (Ba! KANON!), bo przy takiej wiedzy "mlodego pokolenia" znow
> zaczną nam przychodzic ponaglenia o pilną zapłatę 0.00PLN.

[ciach formułki]

I nie mówcie mi, że na macie NaNa, bo w każdej chwili mieć możecie! 
(sprawdzić, czy nie ksiądz).

	Pozdrawiam, Piotr

AK wrote:

> 1. ile masz takich przypadkow w zyciu (owszem, fraktale).

Z okolic "numerków", to filtry Hogenauera chyba tylko. Tam przepełnienia 
stałoprzecinkowe i ich wzajemna kompensacja
są podstawą całej sztuczki.

	Pozdrawiam, Piotr

Użytkownik "AK"  napisał w wiadomości grup 
dyskusyjnych:qe665k$18po$2@gioia.aioe.org...
On 2019-06-13 15:37, Pszemol wrote:
> "Mateusz Viste" <mateusz@nie.pamietam> wrote in message
>>> 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).
>2. przy dzisiejszych koprocesorach ? Na pewno warto ?
>/Kiedys zdecydowanie tak, wiec absolutnie podejscia nie potępiam/.

Dzisiejsze koprocesory ciagle maja ten sam format liczby double, ktory 
powoduje te błędy.

Wczorajsze koprocesory mialy formaty BCD, ktore akurat pieniadze 
liczyly dokladnie, czy dzisiejsze maja to juz nie wiem.

J.

Użytkownik "AK"  napisał w wiadomości grup 
dyskusyjnych:qe65vo$18po$1@gioia.aioe.org...
On 2019-06-12 16:54, Cezary Grądys wrote:
>No dooobra.
>Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
>(Ba! KANON!), bo przy takiej wiedzy "mlodego pokolenia" znow
>zaczną nam przychodzic ponaglenia o pilną zapłatę 0.00PLN.

>a == b  ->   fabs(a - b) <= EPS
>a != b  ->   fabs(a - b) > EPS

Jak najbardziej.

>a < b   ->   (a - b) < -EPS
>a > b   ->   (a - b) > EPS

No, tu bym sie zastanowil.
Bo ryzykujesz, ze liczbe mniejsza zakwalifikujesz jako wieksza.
Z mozliwymi skutkami w przebiegu programu, bo nagle sie okaze ze np 
pierwiastek z liczby ujemnej liczysz, a przeciez sprawdziles, ze 
powinna byc dodatnia ...

>a <= b  ->   (a - b) <= EPS
>a >= b  ->   (a - b) >= -EPS

To juz chyba nie tak bardzo istotne, biorac pod uwage, ze i tak 
dorzuczamy EPS.

>PS: Oczywiscie EPS moze miec rozna nature i wartosci zaleznie np.
>od domeny (numeryka, finanse itp). Np. Moze byc bezwzgledne, ale
>czesto bywa wzgledne, a w numeryce to juz w ogole...

No wlasnie - moze zalezec od wartosci liczb.

J.

On 2019-06-17 03:44, bartekltg wrote:
> On Sunday, June 16, 2019 at 9:40:44 PM UTC+2, AK wrote:
>> On 2019-06-12 16:54, Cezary Grądys wrote:
>>> W dniu 12.06.2019 o 14:29, Mateusz Viste pisze:
>>>
>>>>
>>>> Prawdziwi programiści nie używają liczb zmiennoprzecinkowych.
>>>>
>>>> Obowiązkowa lektura na wieczór:
>>>> http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf
>>>>
>>>
>>> Nie ma co przesadzać, liczby zmiennoprzecinkowe po to powstały, żeby je
>>> używać. Trzeba tylko porównywać je zakładając pewną dopuszczalną
>>> tolerancję.
>>
>> No dooobra.
>> Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
>> (Ba! KANON!), bo przy takiej wiedzy "mlodego pokolenia" znow
>> zaczną nam przychodzic ponaglenia o pilną zapłatę 0.00PLN.
>>
>> a == b  ->   fabs(a - b) <= EPS
>> a != b  ->   fabs(a - b) > EPS
> 
> Zgoda.
> 
>> a < b   ->   (a - b) < -EPS
>> a > b   ->   (a - b) > EPS
>> a <= b  ->   (a - b) <= EPS
>> a >= b  ->   (a - b) >= -EPS
> 
> A to po co?

Przez symetrię. Tak samo wazne jak powyzsze.

> Ale bardzo często nierórności tego typu
> testuje się do rozdielenia mniejszych i większych,
> wtedy to ma mały sens.

Czytales moj post do konca.

AK

On 2019-06-17 09:02, Mateusz Viste wrote:
> On Sun, 16 Jun 2019 21:53:24 +0200, AK wrote:
>> On 2019-06-14 08:19, Mateusz Viste wrote:
>>> Prawdziwi programiści zakładają, że typ danych jest najwęższy możliwy:
>>> int=16, long=32, long long=64.
>>
>> Niestety to duzy blad :(
> 
> Jakieś argumenty?

Pogłówkuj:)

No dobra...
Bo piszą np. potem takie z gruntu błędne konstrukcje.

int a = cus_tak;

if ( x & 0xFFDF )

AK

On 2019-06-17 09:43, Piotr Wyderski wrote:
> 
> I nie mówcie mi, że na macie NaNa, bo w każdej chwili mieć możecie! 

Raaaacja :)

AK

On 2019-06-17 09:48, Piotr Wyderski wrote:
> AK wrote:
> 
>> 1. ile masz takich przypadkow w zyciu (owszem, fraktale).
> 
> Z okolic "numerków", to filtry Hogenauera chyba tylko.

Uj nie mam pojecia co to jest :(

AK

On 2019-06-17 16:09, J.F. wrote:

> 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 :)

> 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".

PS: "My" akurat w defBank-u stosowalismy zwykle double i jakos Assecco
sie z tego powodu do dzis nie przekrecilo :)

AK

On 2019-06-17 16:14, J.F. wrote:
> Użytkownik "AK"  napisał w wiadomości grup 
> dyskusyjnych:qe65vo$18po$1@gioia.aioe.org...
> On 2019-06-12 16:54, Cezary Grądys wrote:
>> No dooobra.
>> Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
>> (Ba! KANON!), bo przy takiej wiedzy "mlodego pokolenia" znow
>> zaczną nam przychodzic ponaglenia o pilną zapłatę 0.00PLN.
> 
>> a == b  ->   fabs(a - b) <= EPS
>> a != b  ->   fabs(a - b) > EPS
> 
> Jak najbardziej.
> 
>> a < b   ->   (a - b) < -EPS
>> a > b   ->   (a - b) > EPS
> 
> No, tu bym sie zastanowil.

Sie nie zasanawiaj, tylko uzywaj.
Z pozno na zastanawianie.

> Bo ryzykujesz, ze liczbe mniejsza zakwalifikujesz jako wieksza.
[...]

Kolejny co nie czytal posta do konca.. Eh..

>> a <= b  ->   (a - b) <= EPS
>> a >= b  ->   (a - b) >= -EPS
> 
> To juz chyba nie tak bardzo istotne, biorac pod uwage, ze i tak 
> dorzuczamy EPS.

TAK SAMO stotne jak i powyzsze.
Wszystkie w/w sa ROWNIE istotne.

>> PS: Oczywiscie EPS moze miec rozna nature i wartosci zaleznie np.
>> od domeny (numeryka, finanse itp). Np. Moze byc bezwzgledne, ale
>> czesto bywa wzgledne, a w numeryce to juz w ogole...
> 
> No wlasnie - moze zalezec od wartosci liczb.

I w optymalizacji np. bardzo czesto sa.
No ale co z tego?

AK

On 2019-06-17 09:43, Piotr Wyderski wrote:
> AK wrote:
> 
> I nie mówcie mi, że na macie NaNa, bo w każdej chwili mieć możecie! 

Raaaacja :)

AK

On Wed, 19 Jun 2019 08:18:11 +0200, AK wrote:
> On 2019-06-17 09:02, Mateusz Viste wrote:
>> On Sun, 16 Jun 2019 21:53:24 +0200, AK wrote:
>>> On 2019-06-14 08:19, Mateusz Viste wrote:
>>>> Prawdziwi programiści zakładają, że typ danych jest najwęższy
>>>> możliwy:
>>>> int=16, long=32, long long=64.
>>>
>>> Niestety to duzy blad :(
>> 
>> Jakieś argumenty?
> 
> Pogłówkuj:)
> 
> No dobra...
> Bo piszą np. potem takie z gruntu błędne konstrukcje.
> 
> int a = cus_tak;
> 
> if ( x & 0xFFDF )

I to jest argument z tym, by nigdy nie zakładać że typ zmiennej jest 
najwęższy możliwy? Naprawdę nie rozumiem, co próbujesz przekazać.

Miej litość nad głupszym kolegą i podkręć proszę jasność.

Mateusz

AK wrote:

> 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

W dniu 2019-06-13 o 23:22, bartekltg pisze:
> On Thursday, June 13, 2019 at 3:37:52 PM UTC+2, 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.
> 
> Pieprzenie. No, czyba, że programowanie = frontend.

nie da się, w webówce np część języków wszystkie liczby to 
zmiennoprzecinkowe

-- 
http://kaczus.ppa.pl

Użytkownik "AK"  napisał w wiadomości grup 
dyskusyjnych:qeckl4$1nvk$1@gioia.aioe.org...
On 2019-06-17 16:09, J.F. wrote:
>> 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 :)

Bez znaczenia - problem ciagle ten sam.

Nawiasem mowiac - czy mi sie wydaje, czy ten format 80-bit jest po 
cichutku wycofywany ?

>> 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".

Nie, ale czesto ulatwia.

>PS: "My" akurat w defBank-u stosowalismy zwykle double i jakos 
>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.

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ą.

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

W dniu 19.06.2019 o 13:40, Mateusz Viste pisze:
> 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
> 

Nowi jak nowi, ale żeby wojsko... I niestety były ofiary.

http://www-users.math.umn.edu/~arnold//disasters/patriot.html


KLoSS

On 2019-06-19 09:03, Mateusz Viste wrote:
>> No dobra...
>> Bo piszą np. potem takie z gruntu błędne konstrukcje.
>>
>> int a = cus_tak;
>>
>> if ( x & 0xFFDF )
> 
> I to jest argument z tym, by nigdy nie zakładać że typ zmiennej jest
> najwęższy możliwy? Naprawdę nie rozumiem, co próbujesz przekazać.
> 
> Miej litość nad głupszym kolegą i podkręć proszę jasność.

To, ze przyjecie takiego zalozenia czyni ten kod (jak najbardziej
zgodny z tym zalozeniem) _zwyczajnie bledny_ !
Jesli nie wiesz dlaczego, to Ci zwyczajnie wspolczuję.

AK

On Tue, 25 Jun 2019 21:32:56 +0200, AK wrote:
> On 2019-06-19 09:03, Mateusz Viste wrote:
>>> No dobra...
>>> Bo piszą np. potem takie z gruntu błędne konstrukcje.
>>>
>>> int a = cus_tak;
>>>
>>> if ( x & 0xFFDF )
>> 
>> I to jest argument za tym, by nigdy nie zakładać że typ zmiennej jest
>> najwęższy możliwy? Naprawdę nie rozumiem, co próbujesz przekazać.
>> 
>> Miej litość nad głupszym kolegą i podkręć proszę jasność.
> 
> To, ze przyjecie takiego zalozenia czyni ten kod (jak najbardziej zgodny
> z tym zalozeniem) _zwyczajnie bledny_ !
> Jesli nie wiesz dlaczego, to Ci zwyczajnie wspolczuję.

To potwierdza moje przypuszczenia: kolega ma po prostu trudności z 
rozumieniem słowa pisanego, lub z ogólnie pojętą logiką. Nie będę zatem 
ciągnął tego wątku, bo mija się to z celem.

Tymczasem mogę tylko życzyć szybkiego powrotu do zdrowia.

Mateusz

On 2019-06-25 22:05, Mateusz Viste wrote:
> On Tue, 25 Jun 2019 21:32:56 +0200, AK wrote:
>> On 2019-06-19 09:03, Mateusz Viste wrote:
>>>> No dobra...
>>>> Bo piszą np. potem takie z gruntu błędne konstrukcje.
>>>>
>>>> int a = cus_tak;
>>>>
>>>> if ( x & 0xFFDF )
>>>
>>> I to jest argument za tym, by nigdy nie zakładać że typ zmiennej jest
>>> najwęższy możliwy? Naprawdę nie rozumiem, co próbujesz przekazać.
>>>
>>> Miej litość nad głupszym kolegą i podkręć proszę jasność.
>>
>> To, ze przyjecie takiego zalozenia czyni ten kod (jak najbardziej zgodny
>> z tym zalozeniem) _zwyczajnie bledny_ !
>> Jesli nie wiesz dlaczego, to Ci zwyczajnie wspolczuję.
> 
> To potwierdza moje przypuszczenia: kolega ma po prostu trudności z
> rozumieniem słowa pisanego, lub z ogólnie pojętą logiką. Nie będę zatem
> ciągnął tego wątku, bo mija się to z celem.

"Czyli zwuczajnie nie wiem "osochodzi"/dlaczego w/w kod jest bledny."

> Tymczasem mogę tylko życzyć szybkiego powrotu do zdrowia.

Lekarzem tez jestes rownie "dobrym" jak programista :)?

AK

On Tue, 25 Jun 2019 22:17:17 +0200, AK wrote:
> "Czyli zwuczajnie nie wiem "osochodzi"/dlaczego w/w kod jest bledny."

Miałeś wyjaśnić dlaczego zakładanie że sizeof(int) == 2 jest błędem. Ty 
natomiast podajesz kod, który jest błędny właśnie dlatego, że programista 
tak nie postąpił. Słowem - strzeliłeś samobója, a teraz pajacujesz.

> Lekarzem tez jestes rownie "dobrym" jak programista :)?

Nie trzeba być lekarzem aby dostrzec oczywistą patologię. Co innego aby 
ją nazwać i wyleczyć - ale ja nie mam takich ambicji.

Mateusz

On 2019-06-25 22:45, Mateusz Viste wrote:
> On Tue, 25 Jun 2019 22:17:17 +0200, AK wrote:
>> "Czyli zwuczajnie nie wiem "osochodzi"/dlaczego w/w kod jest bledny."
> 
> Miałeś wyjaśnić dlaczego zakładanie że sizeof(int) == 2 jest błędem. Ty
> natomiast podajesz kod, który jest błędny właśnie dlatego, że programista
> tak nie postąpił.

Otóż postąpił tu: if ( x & 0xFFDF )
Wlasnie tu przyjal, ze sizeof(int) == 2
No i opierajac sie na tym "przyjeciu" wyprodukowal klasyczny bledny kod.

> Nie trzeba być lekarzem aby dostrzec oczywistą patologię. Co innego aby
> ją nazwać i wyleczyć - ale ja nie mam takich ambicji.

Najpierw ulecz swoja "logike" i "wiedze" "programisto"

AK

> Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
> (Ba! KANON!)


To ja poprosiłbym o jakiś patent na odporne na zaokrąglenia rozdzielenie części całkowitej i ułamkowej w zmiennej typu double.



> ponaglenia o pilną zapłatę 0.00PLN


No właśnie.
Przykładowo, muszę zrobić: 12345.6789 zł -> 12345 zł 68 gr

Wiadomo:

double suma, f;
int zlote, grosze;

   ...

   suma += 0.005;

   zlote = (int)suma;
   f = suma - zlote;
   grosze = (int)(f * 100.0);

Problemy mogą pojawić w przypadku wartości praktycznie równych wartościom całkowitym.
Gdyby na skutek jakichś zaokrągleń wartość f okazała się ujemna, to nie ma problemu - (int) i tak "dociągnie" ją do zera.

Gorzej, gdyby np. suma = 1234.9999999999999997, za to teoretycznie f = 0.9999999999999997 za sprawą zabłąkanego bitu na końcu przeskoczyła na f = 1.0000000000000001.
Wtedy wyjdzie 1234 zł 100 gr...

Chyba, że nie potrzebnie się martwię.
Testowałem to wielokrotnie dla miliardów złośliwie wygenerowanych danych "z pogranicza" - ani razu się nie wywaliła.

No, ale... :-)

On 2019-07-12 07:27, DMR wrote:
>> Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
>> (Ba! KANON!)
> 
> To ja poprosiłbym o jakiś patent na odporne na zaokrąglenia rozdzielenie części całkowitej i ułamkowej w zmiennej typu double.
> 
>> ponaglenia o pilną zapłatę 0.00PLN
> 
> No właśnie.
> Przykładowo, muszę zrobić: 12345.6789 zł -> 12345 zł 68 gr
> 
> Wiadomo:
> 
> double suma, f;
> int zlote, grosze;
> 
>     ...
> 
>     suma += 0.005;
> 
>     zlote = (int)suma;
>     f = suma - zlote;
>     grosze = (int)(f * 100.0);
> 
> Problemy mogą pojawić w przypadku wartości praktycznie równych wartościom całkowitym.
> Gdyby na skutek jakichś zaokrągleń wartość f okazała się ujemna, to nie ma problemu - (int) i tak "dociągnie" ją do zera.
> 
> Gorzej, gdyby np. suma = 1234.9999999999999997, za to teoretycznie f = 0.9999999999999997 za sprawą zabłąkanego bitu na końcu przeskoczyła na f = 1.0000000000000001.
> Wtedy wyjdzie 1234 zł 100 gr...
> 
> Chyba, że nie potrzebnie się martwię.
> Testowałem to wielokrotnie dla miliardów złośliwie wygenerowanych danych "z pogranicza" - ani razu się nie wywaliła.
> 
> No, ale... :-)

Proszę bardzo.
To jest drugi KANON (zaokraglanie do int-a):

W Pythonie tak:
     grosze, zlote = math.modf(amount)
     zlote  = int(abs(zlote) + 0.5)
     grosze = int(abs(grosze) * 100.0 + 0.5)

W C/C++ cuś w rodzaju:
     double zlote_fp;
     double grosze_fp = modf(amount, &zlote_fp);
     long zlote  = long(fabs(zlote_fp) + 0.5);
     int  grosze = int(fabs(grosze_fp) * 100.0 + 0.5);

PS: Wazne jest to + 0.5. Jeszcze z Algolu pamietam:)
integer := ENTER(float + 0.5)

AK

> modf


Funkcje biblioteczne dobre na wszystko! :-)
Tylko, one też muszą być jakoś zaimplementowane.

Tu kolega miał podobny dylemat: https://stackoverflow.com/questions/2637714/
Pytanie - czy na pewno jest to to stabilne numerycznie?
Tzn. czy nawet jakieś wyjątkowo perfidne błędy zaokrągleń przy odejmowaniu nie są w stanie zniweczyć warunku: 0 < floatPart < 1?
(w moim przypadku: floatPart < 1)

On 2019-07-14 10:16, DMR wrote:
>> modf
> 
> 
> Funkcje biblioteczne dobre na wszystko! :-)
> Tylko, one też muszą być jakoś zaimplementowane.

np. Python:
w_groszach = int(abs(amount) * 100.0 + 0.5)
zlote  = w_groszach // 100
grosze = w_groszach % 100

AK

W dniu piątek, 12 lipca 2019 07:27:56 UTC+2 użytkownik DMR napisał:
> > Zamieszcze tu po raz 473 w ciagu 20 lat podstawową formułkę
> > (Ba! KANON!)
> 
> 
> To ja poprosiłbym o jakiś patent na odporne na zaokrąglenia rozdzielenie części całkowitej i ułamkowej w zmiennej typu double.
> 
> 
> 
> > ponaglenia o pilną zapłatę 0.00PLN
> 
> 
> No właśnie.
> Przykładowo, muszę zrobić: 12345.6789 zł -> 12345 zł 68 gr
> 
> Wiadomo:
> 
> double suma, f;
> int zlote, grosze;
> 
>    ...
> 
>    suma += 0.005;
> 
>    zlote = (int)suma;
>    f = suma - zlote;
>    grosze = (int)(f * 100.0);
> 
> Problemy mogą pojawić w przypadku wartości praktycznie równych wartościom całkowitym.
> Gdyby na skutek jakichś zaokrągleń wartość f okazała się ujemna, to nie ma problemu - (int) i tak "dociągnie" ją do zera.
> 
> Gorzej, gdyby np. suma = 1234.9999999999999997, za to teoretycznie f = 0.9999999999999997 za sprawą zabłąkanego bitu na końcu przeskoczyła na f = 1.0000000000000001.
> Wtedy wyjdzie 1234 zł 100 gr...
> 
> Chyba, że nie potrzebnie się martwię.
> Testowałem to wielokrotnie dla miliardów złośliwie wygenerowanych danych "z pogranicza" - ani razu się nie wywaliła.
> 
> No, ale... :-)

chyba cos kolega piepszy

   zlote = (int)suma;
   f = suma - zlote;
   grosze = (int)(f * 100.0);

nie chce mi sie nad tym za dlugo zastanawiac ale na oko to bedzie dzialac
zawsze poprawnie (zakladam ze wartosc suma jest dodatnia i ze chodzi o zaokraglenie w dol, nie mam pojecia jakie reguly zaokraglania pieniedzy panuja w bankach)

Chyba coś kolega "piepszy".

Nie chce mi się tego czytać, ale na oko właśnie tak jest.

On 2019-07-24 19:19, DMR wrote:
> Chyba coś kolega "piepszy".
> 
> Nie chce mi się tego czytać, ale na oko właśnie tak jest.

To po prostu upierdliwy troll.

AK

W dniu środa, 24 lipca 2019 19:19:36 UTC+2 użytkownik DMR napisał:
> Chyba coś kolega "piepszy".
> 
> Nie chce mi się tego czytać, ale na oko właśnie tak jest.

to swietnie bo na wykłocanie sie z matolkami nie mam czasu

On 2019-07-24 22:39, fir wrote:

> to swietnie bo na wykłocanie sie z matolkami nie mam czasu

No jakze to?
Przecie tu na grupie "od lat" gadasz glownie sam z soba ?

AK

Sorunia za crossa, ale tu też o tym pisałem. :-)



> Przykładowo, muszę zrobić: 12345.6789 zł -> 12345 zł 68 gr
> 
> Wiadomo:
> 
> double suma, f;
> int zlote, grosze;
> 
>    ...
> 
>    suma += 0.005;
> 
>    zlote = (int)suma;
>    f = suma - zlote;
>    grosze = (int)(f * 100.0);
> 
> Problemy mogą pojawić w przypadku wartości praktycznie równych
> wartościom całkowitym.
> Gdyby na skutek jakichś zaokrągleń wartość f okazała się ujemna,
> to nie ma problemu - (int) i tak "dociągnie" ją do zera.
> 
> Gorzej, gdyby np. suma = 1234.9999999999999997, za to teoretycznie
> f = 0.9999999999999997 za sprawą zabłąkanego bitu na końcu przeskoczyła
> na f = 1.0000000000000001.
> Wtedy wyjdzie 1234 zł 100 gr...


Ale jeśli zrobię tak:

grosze = (int)(f * 99.99);

to problem zniknie raz na zawsze.
Rzecz jasna, wtedy sumy typu x.9951 zł przejdą na x zł 99 gr, co oczywiście formalnie jest błędem, ale - z drugiej strony - jeszcze poważniejszym błędem jest zaokrąglanie sum do pełnych groszy, przy jednoczesnym rozbijaniu tematu o pojedyncze miligrosze.

No, ale pytanie jest zasadnicze - czy na skutek zaokrągleń, możliwe jest zajście przypadku:

(Double - (int)Double) * 1Ex >= 1Ex

dla "rozsądnych" wartości x (biorąc po uwagę zakresy typów, powiedzmy: 0-8)?
Ktoś może potwierdzić/zaprzeczyć?