Derek, 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 either.
My apologies. Thomas 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 > <tho...@2worthingtons.net> 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 >>> help-smalltalk@gnu.org >>> https://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list help-smalltalk@gnu.org https://lists.gnu.org/mailman/listinfo/help-smalltalk
