|Syntactic Confectionery Delight|
Raku's solution seems far better than the Py3 one, because people expect decimal DWIM
I don't expect (or even want) "decimal DWIM" of NVs ... which, indeed, says something about the different priorities that you and I have.
And I've no objection to raku's propensity for rational arithmetic.
However, raku does allow for floating point values (doubles), and if you get raku to print these values you will find that they generally provide the same as py3:
AIUI, both python3 and raku use the grisu3 algorithm, which is pretty quick. However grisu3 is not suitable for all values, and when such values are encountered raku falls back to sprintf("%.17g", ..) formatting.
Py3 apparently falls back to the "dragon4" algorithm. (Not exactly sure of what python3 does.)
I've gleaned most of that from a post by Zoffix, and from other comments he has made (but that I can't locate).
But you'll find that, for those values where grisu3 fails, raku produces "%.17g" formatting whereas py3 might output less than 17 digits.
I know that no-one's particularly interested, but here's an example of what happens when the double that has been assigned the value 5.3130431399669280e-34 is printed.
On raku, grisu3 fails, and we fall back to "%.17g" formatting:
Perl's output is the only one I find objectionable because it's the only one of the 3 different outputs that doesn't assign to the original value.
The one noteworthy thing about 15-digit decimals is that, if the digits differ, then the values of the doubles that they assign to also differ.
So, eg, you will know just by looking that the 15-digit decimals 12345678901234.1 and 12345678901234.2 assign to different doubles.
But as soon as you go beyond 15-decimal digits, that assurance is lost. For example, with 16 digits, 9.007199254740993e+15 and 9.007199254740992e+15 assign to exactly the same double, even though the digits differ.