2017-11-09 23:50 GMT+01:00 <raffaello.giulie...@lifeware.ch>:
> On 2017-11-09 22:11, Nicolas Cellier wrote: > > > > Something like exact difference like Martin suggested, then > > converting to nearest Float because result is inexact: > > ((1/10) - 0.1 asFraction) asFloat > > > > This way, you would have a less surprising result in most > cases. > > But i could craft a fraction such that the difference > > underflows, and the assertion a ~= b ==> (a - b) isZero not > > would still not hold. > > Is it really worth it? > > Will it be adopted in other dialects? > > > > > > > > As an alternative, the Float>>asFraction method could return the > > Fraction with the smallest denominator that would convert to the > > receiver by the Fraction>>asFloat method. > > > > So, 0.1 asFraction would return 1/10 rather than the beefy > > Fraction it currently returns. To return the beast, one would > > have to intentionally invoke asExactFraction or something > similar. > > > > This might cause less surprising behavior. But I have to think > more. > > > > > > No the goal here was to have a non null difference because we need > > to preserve inequality for other features. > > > > Answering anything but a Float at a high computation price goes > > against primary purpose of Float (speed, efficiency) > > If that's what we want, then we shall not use Float in the first > place. > > That's why I don't believe in such proposal > > > > The minimal Fraction algorithm is an intersting challenge though. > > Not sure how to find it... > > I'm thinking of a continuous fraction expansion of the exact fraction > until the partial fraction falls inside the rounding interval of the Float. > > Heavy, but doable. > > Not sure, however, if it always meets the stated criterion. > > > then look at asApproximateFraction and change the termination condition
