Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Num.FatRat coercion is inexact #5525

Open
p6rt opened this issue Aug 3, 2016 · 1 comment
Open

Num.FatRat coercion is inexact #5525

p6rt opened this issue Aug 3, 2016 · 1 comment
Labels

Comments

@p6rt
Copy link

p6rt commented Aug 3, 2016

Migrated from rt.perl.org#128828 (status was 'new')

Searchable as RT128828$

@p6rt
Copy link
Author

p6rt commented Aug 3, 2016

From zefram@fysh.org

my $a = 2476979795053773e0 * (2e0**-51)
1.1
($a * (2e0**51)).Int
2476979795053773
($a * (2e0**51)) % 1e0
0
$a.FatRat.perl
FatRat.new(11, 10)

The Num->FatRat conversion is being performed inexactly. Every finite
Num value is in fact rational, and therefore exactly representable as a
FatRat, so I would expect the coercion to preserve the value exactly.
It should come out as FatRat.new(2476979795053773, 2251799813685248).
Not only is 11/10 not the exact value of this Num, it's not the exact
value of any Num, because the floating point format can only represent
values whose denominators are powers of two.

The same considerations would not in general apply to the .Rat coercion.
Because the Rat type is intended to have a limited range of denominators,
it cannot exactly represent all Num values. However, I believe the
denominator in this particular case, 2**51, is in the intended range.
So in this case $a.Rat also ought to be exact, but actually it also isn't.

Note that in the above there is no rounding in the decimal->float
conversion​: the large integer value is less than 2**52, and so fits into a
float with a bit to spare. There is also no rounding in the power-of-two
or in the multiplication, which just changes the exponent of the float.
So the Num $a exactly represents the value that is suggested by the way
it was computed. The .Int and %1 operations illustrate the exact value.

-zefram

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant