in reply to Re^3: Largest integer in 64-bit perl
in thread Largest integer in 64-bit perl

The discussion in this thread is about the side effects of implicit typecasting/conversions of whole numbers to augment precision when operations may cause an overflow.

Perl does this by switching to double floats with E0 were the mantissa has 53 bits (opposed to integers with 32 or 64 bits, depending on the built).

Now from what I read on Wikipedia is Rust strictly typed.

Hence I really don't understand what your code is supposed to show.

Is there any implicit typecasting in your code?°

update

According to this tutorial: https://oylenshpeegul.gitlab.io/from-perl-to-rust/numbers.html this can't be, because coercion has to be made explicitly.

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re^5: Largest integer in 64-bit perl
by syphilis (Archbishop) on May 30, 2025 at 00:41 UTC
    Perl does this by switching to double floats ...

    Rather, perl switches to "NV" floats.
    Of course, I'm nitpicking, but it's a nitpick that does have some significance.
    On a perl whose ivsize=8, && whose nvtype is either 'long double' or '__float 128', I get: 
    D:\>perl -e "print 'wtf' unless ~0 < (~0) + 1;"

D:\>

    [download]
    But on a perl where ivsize=8 and nvtype is 'double' and you get: 
    D:\>perl -e "print 'wtf' unless ~0 < (~0) + 1;"
wtf
D:\>

    [download]
    Now that particular configuration (ivsize==8 and nvtype is 'double') is the only perl configuration that produces that nonsense - and yet it's the most commonly used configuration !!
    If you use either an ivsize of 4, or an nvtype that is not double, then you can ignore that particular weirdness because it's not going to happen.

    Note: That "nonsense" doesn't just happen with (~0) + 1. It happens for (~0) + $x for all $x in the range 1..2048.
    That's mainly why I think of it as an insane configuration. (It's still a configuration that I regularly use ;-)

    Cheers,
    Rob
[reply]
[d/l]
[select]
      So what do you expect to happen if you construct the max unsigned integer via bitwise inverting zero ~0 and adding 1 ?

      You are talking about "weirdness", so what would be "normal" in your opinion.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

[reply]
[d/l]
[select]
        You are talking about "weirdness", so what would be "normal" in your opinion.

        I just find it weird that, on a platform where 64-bit positive integer values can be stored exactly, it is considered acceptable that all other integer values be rounded to 53 bits of precision.
        I would find it quite acceptable if positive integer values greater than 64 bits were rounded to 64-bit (or greater) precision values, but cutting them back to 53-bit precision values seems a very poor alternative.
        My gripe is not so much about how perl handles this configuration, but that this daft configuration is so widely used and accepted as valid. (I guess I should be grateful that the chosen default NV was the double precision one, and not the single precision float ;-)

        Of course, people are free to accept whatever they like, and thankfully it's easy enough to find modules (or to use a sanely configured perl build) such that precision is not reduced to below-integer precision when the integer value overflows integer precision.

        Cheers,
        Rob
[reply]
        The most sensible approach is to break out bigint/bigrat when it is needed. It's a scripting language, afterall, where we didn't get to declare the types. Python does it, and what would have been Perl 6 did it. I think it would be quite sensible for someone to come up with a new Perl 5 feature flag called use experimental "rational_math"; and bundle a copy of GMP with perl (or Tom-math or something) and have perl seamlessly support rational numbers. It would be much more "normal" than asking for "please give me a semi-arbitrary circumstantial mixture of double and int64_t".

        Of course, that's a huge amount of work to specify and implement and write tests for, so I don't expect it to happen. But it would have saved me an awful lot of grief with rounding problems related to money over the years.

[reply]
[d/l]
Re^5: Largest integer in 64-bit perl
by karlgoethebier (Abbot) on May 30, 2025 at 08:55 UTC
[reply]

In Section Seekers of Perl Wisdom