|The stupid question is the question not asked|
Re^2: portably finding max integerby martin (Pilgrim)
|on May 25, 2009 at 14:07 UTC||Need Help??|
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.
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.