Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:qdqqh6$n2f$...@d...me...
>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ł...

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

To nie jest problem VB, to jest problem przyjetego formatu liczb
rzeczywistych.
Albo problem programisty :-)

31 jest dokladne, 0.8 nie.
0.5 jest dokladne, 0.25 i 0.75 itd - ale wiekszosc liczb "dziesietnych
po przecinku" niestety nie.

Po prostu nie da sie zapisac 32.8 dokladnie.
Programista ma o tym wiedziec i sie zabezpieczyc :-)

>Czy inne Visuale jak VC++ lub VC# też tak mają?

To jest problem procesora z FP IEEEcostam.

Akurat .net ma dodatkowe formaty (Decimal), w ktorych powinno to
dzialac.
Tylko trzeba ie
Ale i tak bym dorzucil zabezpieczenie.

Problem promieniuje na bazy danych, gdzie mamy duzo kwot, a te grosze
tez nie sa dokladne :-)

J.