Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: portably finding max integer

by BrowserUk (Pope)
on May 24, 2009 at 20:57 UTC ( #765950=note: print w/ replies, xml ) Need Help??


in reply to portably finding max integer

It would be a premature pessimisation to move to using Math::BigInt on a 32-bit integer machine until you've exploited the ability of doubles to hold 53-bit integers accurately. That would make the breakpoint: 9007199254740992.

If there is any chance of a version of perl using something other than a 64-bit double, then you can determine the break point dynamically using:

my $n = 2; $n *=2 until $n+0.5 == $n; $n *=2; print $n;

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.


Comment on Re: portably finding max integer
Download Code
Re^2: portably finding max integer
by martin (Pilgrim) on May 25, 2009 at 14:07 UTC
    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.

      Yes, Perl guarantees that IV will be at least 32 bits. And you will have better luck building your Perl so that NVs have more mantissa bits than IVs (if you have 64-bit IV, then use 'long double' for NV) as making allowances for IV being better for some values and NV being better for other values is quite complicated (doomed to fail in some cases, I say) and has also only been introduced to Perl fairly recently.

      - tye        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://765950]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2014-09-03 05:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (35 votes), past polls