develooper Front page | perl.perl6.users | Postings from April 2021

Re: Comparing Int and Num

Thread Previous | Thread Next
From:
sisyphus
Date:
April 16, 2021 06:22
Subject:
Re: Comparing Int and Num
Message ID:
CADZSBj08vp0Pf3hh+xuShC5LUVmDaNWBjsaeP69GZHRscXa4Rw@mail.gmail.com
On Fri, Apr 16, 2021 at 10:21 AM Ralph Mellor <ralphdjmellor@gmail.com>
wrote:

[snip]

>
> my int $i = ...;
> my num $n = $i;
>
>
The conversion from  int to num looks sane.
Of course, we can't assign 64 bit values to an int, so I switched to the
63-bit values 9223372036854775296 and 9223372036854775295.

The first of those should assign to the double as 9.223372036854776e+18
(0x1p+63), and that's exactly what happens for both the 'num' and 'Num'
types:

C:\>raku -e "my int $i = 9223372036854775296; my num $n = $i; say $n;"
9.223372036854776e+18

C:\>raku -e "say 0e0 + 9223372036854775296"
9.223372036854776e+18

However, the second of those integers should assign to the
double 9.223372036854775e+18  (0x1.fffffffffffffp+62) - yet this happens
only for the 'num' case:

C:\>raku -e "my int $i = 9223372036854775295; my num $n = $i; say $n;"
9.223372036854775e+18

C:\>raku -e "say 0e0 + 9223372036854775295"
9.223372036854776e+18

I don't think it's a big deal if that is deemed to be NOT buggy.
We would just have to be mindful of avoiding Nums when we're not prepared
to accept that the usual "round to nearest, ties to even" rule might not be
enforced.
Mind you, it's hard to work out just what rounding rule *is* being enforced
- it's definitely not one that I've ever encountered before.
With "Num" I don't get the correct result until the value drops to
9223372036854775231.

C:\_32>raku -e "say 0e0 + 9223372036854775232"
9.223372036854776e+18

C:\_32>raku -e "say 0e0 + 9223372036854775231"
9.223372036854775e+18

In binary 9223372036854775232 is:
0.11111111111111111111111111111111111111111111111111111 0111000000E63
and  9223372036854775231 is:
0.11111111111111111111111111111111111111111111111111111 0110111111E63

(I've inserted a space between the 53rd and 54th digits.)

It's hard to come up with a rule that decrees that those 2 values should
round to different 53-bit forms.
Though there seems to be a pattern emerging:
 9223372036854775295 -  9223372036854775231 == 64
and from my initial post in this thread:
(18446744073709551615 - 1024) - (18446744073709551615 - 1088) == 64.

I suspect some little optimization trick might be doing something
unexpected.


> I hope to get time to respond to your earlier posts this weekend.
>
>
No rush, and please, don't stress over any of this.

Cheers,
Rob

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About