Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: math problems

by BrowserUk (Patriarch)
on Mar 28, 2011 at 22:24 UTC ( [id://896043]=note: print w/replies, xml ) Need Help??


in reply to math problems

Try %u instead of %d:

printf "%d\n", 9223372036854775808;; -9223372036854775808 printf "%u\n", 9223372036854775808;; 9223372036854775808

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.

Replies are listed 'Best First'.
Re^2: math problems
by kennethk (Abbot) on Mar 29, 2011 at 14:41 UTC
    I suspect this will only mask this issue for the OP. At best, this give the OP a factor of two improvement before he hits the ceiling, and then it transforms an obvious error to a silent one. For example, the code:

    printf "%020u\n%020u\n%020u\n", 9223372036854775808,20000000000000000000,99999999999999999999

    outputs under 64-bit

    09223372036854775808 18446744073709551615 18446744073709551615

    and under 32-bit

    00000000004294967295 00000000004294967295 00000000004294967295

    The swapping to %020.0f puts you at the whims of round-off, with 32-bit yielding

    09223372036854775800 20000000000000000000 100000000000000000000

    and 64-bit yielding

    09223372036854775808 20000000000000000000 100000000000000000000

    That round-off might well be acceptable depending on the specific numbers involved and required accuracy; if not the OP will likely have to resort to Math::BigInt or equivalent.

      I suspect this will only mask this issue for the OP.

      Hm. I don't consider doubling the usable range "masking the problem". More 'taking full advantage of the built-in capabilities whilst dodging the cumbersome and slow bullet of arbitrary precision' until (and if) it is actually required.

      I consider moving to Math::BigInt a very last resort. There are Math::Int64 and Math::Int128 to consider before then.

      But if his numbers will fit into the unsigned capabilities of the Perl he is using, it doesn't make any sense to seek alternatives for the sake of switching from %d to %u.

      I mean, if that is "just masking the problem", then why bother with IVs at all? Why not just have Perl do all math in arbitrary precision and no one would ever encounter these limitations?

      Oh right. I remember why now. Because arbitrary precision is dog slow and most of the time we don;t need it.


      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.
        I agree that doubling the range may be a good solution depending on the input. My experience has shown me that increasing a valid range by a factor of two is generally stop-gap, but without more knowledge of the problem this is pure conjecture.

        I would certainly not promote arbitrary precision in the general case, but in this case the OP has (probably) encountered the native limit, and appears to expect an unreasonable 20-digits of precision based on his format string.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (3)
As of 2024-04-18 23:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found