in reply to Research into occasional participation in Perl/Raku development
Please consider assisting them by taking the survey about your participation in the Perl/Raku community.
Considered ... and declined.
Raku provided the opportunity to drag perl into the 21st century but, in terms of the way that numbers are handled, they opted to stick with an approach that I would term "neanderthal".
So I quickly lost interest. (But that's only because the way that numbers are handled is important to me ... and I do realize that there are others with different priorities.)
To elaborate, here's the approach that python3 chose to follow:
Both the raku and python3 scripts are comparing the same rationals to the same double precision floating point value, and yet they provide different results.
Sure, I get that both of the rationals (1/10 and 3602879701896397/36028797018963968) round to the same double precision floating point value  and that's why raku reports "True" in both instances.
But the thing is that the double 0.1 does have a precise and exact rational value  and that precise and exact rational value is 3602879701896397/36028797018963968 (or, in decimal, 0.1000000000000000055511151231257827021181583404541015625) and not the precise and exact rational value of 1/10 (in decimal, 0.1).
I don't know why raku has made this choice. Anyone ?
The most annoying thing about it is that it implies that (the rational) 1/10 == (the rational) 3602879701896397/36028797018963968 ... yet raku itself will tell you that isn't so (if you explicitly ask it about that).
I'm inclined to think that it was done simply to annoy me ... though, somewhere deep inside, I think that even I realize that I'm probably not quite that important ;)
Cheers,
Rob
Considered ... and declined.
Raku provided the opportunity to drag perl into the 21st century but, in terms of the way that numbers are handled, they opted to stick with an approach that I would term "neanderthal".
So I quickly lost interest. (But that's only because the way that numbers are handled is important to me ... and I do realize that there are others with different priorities.)
To elaborate, here's the approach that python3 chose to follow:
And here's the approach that raku has elected to follow:$ cat demo.py from fractions import Fraction; print (Fraction(1, 10) == 0.1); # False print (Fraction(3602879701896397, 36028797018963968) == 0.1); # True $ python3 demo.py False True
C:\_32>type demo.r my $x = 1/10; say $x.nude; my $y = 3602879701896397/36028797018963968; say $y.nude; say $x == 0.1e0; say $y == 0.1e0; say $y == $x; C:\_32>raku demo.r (1 10) (3602879701896397 36028797018963968) True True False
>type demo.r say 1/10 == 0.1e0; say 3602879701896397/36028797018963968 == 0.1e0; >raku demo.r True True
Sure, I get that both of the rationals (1/10 and 3602879701896397/36028797018963968) round to the same double precision floating point value  and that's why raku reports "True" in both instances.
But the thing is that the double 0.1 does have a precise and exact rational value  and that precise and exact rational value is 3602879701896397/36028797018963968 (or, in decimal, 0.1000000000000000055511151231257827021181583404541015625) and not the precise and exact rational value of 1/10 (in decimal, 0.1).
I don't know why raku has made this choice. Anyone ?
The most annoying thing about it is that it implies that (the rational) 1/10 == (the rational) 3602879701896397/36028797018963968 ... yet raku itself will tell you that isn't so (if you explicitly ask it about that).
I'm inclined to think that it was done simply to annoy me ... though, somewhere deep inside, I think that even I realize that I'm probably not quite that important ;)
Cheers,
Rob


Replies are listed 'Best First'.  

Re^2: Research into occasional participation in Perl/Raku development
by talexb (Chancellor) on Oct 01, 2021 at 23:57 UTC  
by syphilis (Archbishop) on Oct 02, 2021 at 02:48 UTC  
Re^2: Research into occasional participation in Perl/Raku development
by p6steve (Sexton) on Oct 12, 2021 at 21:23 UTC  
by syphilis (Archbishop) on Oct 13, 2021 at 00:25 UTC 
In Section
Meditations