[Top][All Lists]

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

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

From: Thomas Worthington
Subject: Re: [Help-smalltalk] 1e-4 printing bug
Date: Thu, 09 May 2019 21:49:23 +0100
User-agent: mu4e 1.1.0; emacs 26.1

  You're quite right. The name and the comment on the method threw me. It's 
more like IEEE-754AsExactFraction which, now I look at it isn't a great name 

My apologies.


Derek Zhou writes:

> 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:
>>   Are you saying that when I type
>>1e-4 asFraction
>>and get
>>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
>>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
>>(10 raisedTo: -4) asFloat
>>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
>>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

reply via email to

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