laziness, impatience, and hubris  
PerlMonks 
Comment on 
( #3333=superdoc: print w/ replies, xml )  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 floatingpoint 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 floatingpoint precision on 32bit 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 counterexamples 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 64bit machine with IEEE doubles, say), downgrading integer to floatingpoint should be avoided just like downgrading fp to 32bit 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 bitoperations in 64bit unsigned integer but numerical comparison in 53bit signed floatingpoint or something, which means that you can have numerically equal values that are different bitwise (example: 1<<601 versus 1<<60). I'll post a meditation with my findings when I'm done. In reply to Re^2: portably finding max integer
by martin

