Re: 1e-4 printing bug

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
> [email protected]
> https://lists.gnu.org/mailman/listinfo/help-smalltalk