help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] 1e-4 printing bug


From: Derek Zhou
Subject: Re: [Help-smalltalk] 1e-4 printing bug
Date: Thu, 18 Apr 2019 22:02:50 +0800
User-agent: K-9 Mail for Android

1e-4 is a floating number by syntax. as you may know, binary floating number 
cannot hold the exact number of 0.0001, some kind of approximation has to be 
used. 

if you convert a floating number to a fraction, there are 2 methods, one is 
asFraction, the other is asExactFraction. since the memory location of the 
floating number already hold the value tbat is not quite 0.0001, the computer 
has no way to figure out that you mean 0.0001 at the beginning because the 
precision was already lost. so the computer came up with a faithful fraction 
representation of the floating number, so you get 13743895/137438953472

on the other hand, the asFraction is supposed to be an imprecise approximation 
of the floating point number, you get back 1/1000 purely by luck, whatever 
algorithm it use, it happen to pick a fraction that you want. but generally 
speaking, rounding will introduce error. if you call asFloat asFraction 
repeatly, there is no guaranty that you get the value you oringinally had in 
mind.

On April 18, 2019 9:40:41 PM GMT+08:00, Thomas Worthington <address@hidden> 
wrote:
>Derek,
>   Are you saying that when I type
>
>1e-4 asFraction
>
>and get
>
>1/10000
>
>that's wrong, then?
>
>It seems pretty obvious that if asFraction returns the right answer and
>asExactFraction returns the wrong answer, then there is a bug in the
>latter and not the former. Starting with the same input, there is no
>reason why they should return different answers in this particular
>case.
>
>It may simply be a case of asExactFraction being mis-named. The comment
>in the code even uses the word "approximation".
>
>More strangeness:
>
>(10 raisedTo: -4) asExactFraction
>1/10000
>
>(10 raisedTo: -4) asFloat
>0.0001
>
>1e-4
>0.00001
>
>
>So, I think we can firmly state that the problem here is not in the
>output routines. It may in fact be the input routine (i.e., the
>parser).
>
>Thomas
>
>
>Derek Zhou writes:
>
>> Thomas Worthington writes:
>>
>>> If 13743895/137438953472 == 1/10000 then 137438953472/13743895 ==
>10000, which it clearly does not, so it seem to me still to be an
>underlying issue with asExactFraction or some related method.
>>
>> 1e-4 is a floating point number which is not the same as 1/10000 the
>> fraction.
>>
>> _______________________________________________
>> help-smalltalk mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/help-smalltalk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]