"J.F." <j...@p...onet.pl> wrote in message
news:5d00f430$0$17345$65785112@news.neostrada.pl...
> 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.

Teraz jak czytam co napisałeś to wydaje się to oczywiste.
Ale taki byłem szczęśliwy że wreszcie znalazłem buga i uruchomiłem
program że samamu mi się ta klapka w mózgu nie odklapiła - dzięki.