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

Rat.perl doesn't round-trip numerical value #4550

Open
p6rt opened this issue Sep 18, 2015 · 4 comments
Open

Rat.perl doesn't round-trip numerical value #4550

p6rt opened this issue Sep 18, 2015 · 4 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Sep 18, 2015

Migrated from rt.perl.org#126102 (status was 'open')

Searchable as RT126102$

@p6rt
Copy link
Author

p6rt commented Sep 18, 2015

From zefram@fysh.org

$ ./perl6 -e 'my $a = 0.89999999999999999999; my $b = $a.perl.EVAL; say $a.WHICH; say $b.WHICH'
Rat|89999999999999999999/100000000000000000000
Rat|9/10

$a.perl is "0.9", which is not an accurate reflection of its true value.
If the 8 digit is changed to 9, the .perl output is "0.A", which is even
more bogus.

-zefram

@p6rt
Copy link
Author

p6rt commented Sep 19, 2015

From @labster

You've reported the wrong bug. The value you created shouldn't be a Rat at all.

my $a = 0.89999999999999999999; ([/] $a.nude).WHAT.say
(Num)
$a.denominator > $UINT64_UPPER;
True

So this ticket (and #​126016) are fallout from the fact that the distinction between Rat and FatRat is only partially implemented. See http://design.perl6.org/S02.html#Numeric_Types

On Fri Sep 18 13​:24​:54 2015, zefram@​fysh.org wrote​:

$ ./perl6 -e 'my $a = 0.89999999999999999999; my $b = $a.perl.EVAL;
say $a.WHICH; say $b.WHICH'
Rat|89999999999999999999/100000000000000000000
Rat|9/10

$a.perl is "0.9", which is not an accurate reflection of its true
value.
If the 8 digit is changed to 9, the .perl output is "0.A", which is
even
more bogus.

-zefram

@p6rt
Copy link
Author

p6rt commented Sep 19, 2015

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Dec 1, 2017

From @AlexDaniel

OK, there are two problems mentioned in the report. The second one (with 0.A being created) is part of RT#​126016 which is now resolved. ✓

As for the other issue, the behavior has changed a little bit​:

my $a = 0.89999999999999999999; my $b = $a.perl.EVAL; say $a.WHICH; say $b.WHICH

¦c8ec2999bee^​:
«Rat|89999999999999999999/100000000000000000000␤Rat|9/10␤»

¦c8ec299,HEAD(5929887)​:
«Rat|89999999999999999999/100000000000000000000␤Rat|89999999999999999999/100000000000000000000␤»

The commit in question is (2015-09-25) rakudo/rakudo@c8ec299

As already mentioned, the problem is a little bit different. Rats with too big denoms are weird, and there's a ticket for that​: RT#​132313

I'll interlink the tickets and leave this open.

On 2015-09-19 00​:28​:52, labster wrote​:

You've reported the wrong bug. The value you created shouldn't be a
Rat at all.

my $a = 0.89999999999999999999; ([/] $a.nude).WHAT.say
(Num)
$a.denominator > $UINT64_UPPER;
True

So this ticket (and #​126016) are fallout from the fact that the
distinction between Rat and FatRat is only partially implemented. See
http://design.perl6.org/S02.html#Numeric_Types

On Fri Sep 18 13​:24​:54 2015, zefram@​fysh.org wrote​:

$ ./perl6 -e 'my $a = 0.89999999999999999999; my $b = $a.perl.EVAL;
say $a.WHICH; say $b.WHICH'
Rat|89999999999999999999/100000000000000000000
Rat|9/10

$a.perl is "0.9", which is not an accurate reflection of its true
value.
If the 8 digit is changed to 9, the .perl output is "0.A", which is
even
more bogus.

-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