Derek, It's about six months since I looked at it so I may be mis-remembering. I'll see if I can find any record of my own attempt at this bug. I do remember starting from scratch and ending up with the same algorithm which gives 13743895/137438953472 instead of 1/10000 at which point I felt I'd failed and set it aside.
In what sense do you mean that 13743895/137438953472 is "technically correct"? 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. Thomas Derek Zhou writes: > Thomas Worthington writes: > >> Derek, >> The issue is an underlying one in how numbers are converted to exact >> fractions as part of the printing process; the problem needs to be addressed >> there since it will be affecting more than just printing. > > I don't know why printing of float has to go through exact fraction, nor > why 1e-4 is converted to 13743895/137438953472 instead of 1/10000, > however 13743895/137438953472 is technically correct; while printing of > it is wrong. This patch fixed a bug so printing of 1e-4 through > 13743895/137438953472 is correct again; which I think is a good > thing. Whether we should improve converting to exact fraction or skip > the convertion altogether is a seperate issue. > > Derek > > _______________________________________________ > 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
