You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey @nsajko, thanks for discovering this surprising behavior! It seems that, in this case, the extra limb computed in clean mode is not quite cancelled out in the multiplication x * inv(x), producing a number that is very slightly different from 1.0.
This behavior is counterintuitive but actually correct. The number (1/3)^100 cannot be exactly represented as a terminating decimal in base 2, so you should not expect inv(3.0^100) to be the exact multiplicative inverse of 3^100. Indeed, if we compare using BigFloat:
You can see that clean mode correctly produces a more accurate result. Therefore, there is no bug here. The only issue is the false expectation that isone(x * inv(x)) hold for any x whose multiplicative inverse cannot be exactly represented.
Here's a case where MultiFloats "clean" mode is worse than "standard" mode. To make matters worse, "clean" mode is worse than
Float64
in this case:So there seems to be a bug somewhere in "clean" mode.
The text was updated successfully, but these errors were encountered: