Many thanks for the responses.
It turns out there is more to consider about doing precise integer arithmetic in Perl than what I originally asked.
The perlop documentation shmem brought to my attention gives a formula for a big integer value but also mentions that most arithmetic is carried out in floating-point by default. The integer pragma can change that but will also have consequences for signed/unsigned, division and modulus semantics.
jwkrahn demonstrated that the POSIX module provides an own set of various numerical limits.
I guess, however, that those apply to this particular interface rather than to perl internals.
Finally, BrowserUk suggested exploiting floating-point precision on 32-bit machines and gave a code snippet probing for the precision actually available.
One question that has not been answered yet is whether 31 bit for positive values was as bad as it can get.
I have found no counter-examples so far.
In short, **there are more factors determining whether an arithmetic result can be expected to be precise than a simple size check**.
I'll have to look more closely into automatic numerical type conversion and how perl handles individual operators.
For example, on a machine with less precision in floats than in integers (a 64-bit machine with IEEE doubles, say), downgrading integer to floating-point should be avoided just like downgrading fp to 32-bit integer on other machines.
But this may be hard to accomplish if the underlying model suggests that integers are considered a subset of floats.
I have already found a perl that will do bit-operations in 64-bit unsigned integer but numerical comparison in 53-bit signed floating-point or something, which means that
you can have numerically equal values that are different bit-wise (example: `1<<60|1` versus `1<<60`).
I'll post a meditation with my findings when I'm done. |
Comment onRe: portably finding max integerDownloadCode