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