in reply to perl arithmetic is killing me! HELP!

Can somebody explain to me how to do 32-bit operations in Perl?

I wouldn't be very comfortable doing 32-bit unsigned integer operations in perl if overflows can occur. I'd probably do it in C and access the operations from perl via Inline::C or XS.
As already mentioned, 'use integer', is probably of value though I wouldn't like to vouch for its reliability - especially on a perl version as old as 5.8.

I don't know what "TinyPerl" is - could you provide the output of perl -V (that's an uppercase "V").

But on the first line, I get -1, and on the second line I get the positive number in base 10

As you've noted, "-1" and "4294967925" are the same 32-bit integer.
On the first line you asked for it to be expressed as a signed value (ie -1). On the second line you got to see the unsigned value (4294967295).
It seems to me that since you're actually interested in the unsigned values, the first line should have specified "%u" instead of "%d".

But, of course, the value you really expected to see was 855638016, for which you need to satisfy 2 requirements:
1) That you 'use integer'
2) That the size of your perl's integer is 4 bytes (check perl -V:ivsize).

With both of those conditions satisfied I get: 
LINE 1: 855638016 == 855638016
LINE 2: 855638016 == 855638016

[download]
But if perl's integer is 8 bytes then, irrespective of whether I 'use integer', I get: 
LINE 1: 855638016 == 5150605312
LINE 2: 855638016 == 855638016

[download]
Note that, in this instance, the "%d" in "LINE 1" is providing a signed 64-bit value because the perl integer is a 64-bit type.

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: perl arithmetic is killing me! HELP!
by marto (Cardinal) on Nov 07, 2018 at 12:46 UTC
[reply]
Re^2: perl arithmetic is killing me! HELP!
by ikegami (Patriarch) on Nov 07, 2018 at 13:34 UTC

    The actual requirements:

    • That you 'use integer'
    • That the size of your perl's integer is 4 bytes (check perl -V:ivsize) or that you use & 0xFFFF_FFFF.
[reply]
[d/l]
      The actual requirements:
      •That you 'use integer'
      •That the size of your perl's integer is 4 bytes (check perl -V:ivsize) or that you use & 0xFFFF_FFFF

      I think there's at least one more condition, namely: Do not assign a value that's greater than UINT_MAX.

      I don't know what others expect to happen when, having chosen to 'use integer', one assigns (to a perl scalar) a value that is greater than UINT_MAX, but the result is one that I do not expect.
      This is behaviour that I do expect when ivsize is 4: 
      C:\> perl -Minteger -wle "$x = 4294967295 + 3;print $x;"
2

      [download]
      And I expect the same output when I do: 
      C:\> perl -Minteger -wle "$x = 4294967298;print $x;"
4294967298

      [download]
      Alas, such handling of this corner case leaves me feeling uneasy about using the integer pragma at all.

      How many other surprises (or traps for the unwary) are to be found in the finer details of this pragma's behaviour ?

      Cheers,
      Rob
[reply]
[d/l]
[select]

        I think there's at least one more condition, namely: Do not assign a value that's greater than UINT_MAX.

        No, that's not a precondition, because not assigning a value greater than (or equal to) "UINT_MAX" is exactly what the OP is trying to do.

        but the result is one that I do not expect

        It is not only the result the OP wants, it's the result you should expect since Perl's integer addition is implemented as a C integer addition. The result should be the 32 lower-order bits of the sum.

        Alas, such handling of this corner case

        integer clearly says it "only affects how most of the arithmetic and relational operators handle their operands and results, and not how all numbers everywhere are treated" and proceeds to list the specifics.

[reply]

In Section Seekers of Perl Wisdom