in reply to Re: use bignum and exponentiation
in thread use bignum and exponentiation

However, one of the bignum samples:

perl -Mbignum -le 'print sqrt(33)'

behaves in one of the ways I would expect, in that it returns:

5.74456264653802865985061146821892931822

The other way I would expect would be for it to return 5, which would be cosnistent with 33 being treated as an integer.

Also, another sample:

perl -Mbignum -le 'print 2 ** 0.5' returns: 1.41421356237309504880168872420969807857

This is also inconsistent with 2**0.5 being treated as an integer.

Returning NaN for raising an integer to a negative power is not consistent with the documentation (nowhere is it said that "raising an integer to a negative power results in NaN) and it is also inconsistent with other Perl behavior (1/10 doesn't return NaN)

Also, I just tried (on my FreeBSD box, at home) this:

perl -Mbignum -le 'print 10.01 ** -1'

and had it returned

0.0999000999000999000999000999000999000999

This is consistent with syphilis' conmments.

emc

At that time [1909] the chief engineer was almost always the chief test pilot as well. That had the fortunate result of eliminating poor engineering early in aviation.

—Igor Sikorsky, reported in AOPA Pilot magazine February 2003.

Replies are listed 'Best First'.
Re^3: use bignum and exponentiation
by syphilis (Archbishop) on Dec 03, 2006 at 06:53 UTC
    The other way I would expect would be for it to return 5, which would be cosnistent with 33 being treated as an integer.

    A return of "5" is what I would have expected. Afaict, the "33" is a Math::BigInt object, yet for some reason the module's author has apparently decided to implement some cross-class overloading and have a Math::BigFloat object returned when sqrt() is called with 'use bignum'. I guess, therefore, it might be possible (via some recoding of the bignum module) to have the overloaded ** operator return a Math::BigFloat object when the exponent is a negative integer.

    I don't particularly like cross-class overloading ... it's a cute and clever thing to do, but one just doesn't know in advance what one is going to get in return. And there's no guarantee that DWIMness is being met, anyway. I would recommend that one uses Math::BigInt/Math::BigFloat instead of bignum.

    (I could be way off with my diagnosis ... I haven't delved into the source to verify that I've got it right. I have made my assessments based on a few test programs that Devel::Peek::Dump()ed the various arguments and returns.)

    Cheers,
    Rob

      I've not dug into the bignum code (and probably won't). I will, however, tend to avoid bignum for serious work.

      I also found that bignum is consistent, at least for small integers and small powers: for any base except 1 (I suspect 1**x is optimized away), and for any exponent, $x**$y returns NaN for 0 < $x ≤ 1000 for $y = -1 and when $x == 10 and -100 ≤ $y ≤ -1.

      So, my bigger question is: why isn't this a caveat in bignums documentation?

      emc

      At that time [1909] the chief engineer was almost always the chief test pilot as well. That had the fortunate result of eliminating poor engineering early in aviation.

      —Igor Sikorsky, reported in AOPA Pilot magazine February 2003.
      bignum - Transparent BigNumber support for Perl

      Nothing about integers there.

      --
      In Bob We Trust, All Others Bring Data.