Re: bignum incompatible with looks_like_number() ???

In article <4681d0e6$0$8915$afc38c87@xxxxxxxxxxxxxxxxxxxx>,
"Sisyphus" <sisyphus1@xxxxxxxxxxxxxxxxx> wrote:

This works fine, except that I'm getting answers that are a little off
numerically.

because decimal fractions like 0.000001 cannot be
represented with complete accuracy in the internal binary form that
computers use (irrespective of the number of bits of precision that have
been allocated).

Yeah, that's exactly why I'm trying to use bignum -- to extend the
precision out far enough so that data representation errors are below
the radar. My boss's radar certainly notices a 500 ppm error, which is
what I'm getting from Financials::Math::IRR --- which incidentally
brags about being used and tested extensively in serious financial
environments.


which SHOULD pass the looks_like_number test, but it doesn't.

No - it's a Math::BigFloat object, which looks nothing like a number to
(both me and) Scalar::Util::looks_like_number().

That answer seems so far out of line with the Perl philosophy that I'm
having trouble believing it.

Firstly, the number in Math::BigFloat format is clearly +1E-6 when you
remove the OPCODEs --- which sure looks like a number to me.

Secondly, does 40490FD0 look like a number? It's 3.14159 in floating
point hex. You can't judge a number by its numerals.

Finally, I cannot believe Larry would allow fundamental things like
bignums and looks_like_number() to be incompatible --- they are both
essentially part of the Perl distro.

If you can't trust those, what parts of Perl CAN you trust?

Is there a better answer?

CB

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
.

Relevant Pages

  • Re: bignum incompatible with looks_like_number() ???
    ... computers use (irrespective of the number of bits of precision that have ... precision out far enough so that data representation errors are below ... Financial::Math::IRR apparently accommodates only 53 bits of precision - or however many bits of precision that an NV provides on your build of perl. ... the same name) thought that bignum objects looked like a number then there would be no need for the bignum package to exist in the first place. ...
    (comp.lang.perl.modules)
  • Re: float bug? perl 5.8, DBI and oracle 10.2.0
    ... precision numbers in oracle, you've got 38 decimal digits to play ... and with minimal coaxing perl will handle them as ... digits from a 32 bit floating point number - I'll go out on a limb ... and hazard that one can expect 12 or so digits from a 64 bit floating ...
    (perl.dbi.users)
  • RE: float bug? perl 5.8, DBI and oracle 10.2.0
    ... It's made worse by the binary representation used for floating point on ... expecting to see zero, is not going to work in general. ... perl 5.8, DBI and oracle 10.2.0 ... a number with decimals in it (a float). ...
    (perl.dbi.users)
  • Re: The spinoza papers: design of the extra-precision number object 2
    ... doesnt terminate, which cause practical problems, e.g in representation ... that we have an exact number. ... Limiting the precision doesn't change this claim. ... including quantum uncertainty represented as ...
    (comp.programming)
  • Re: more than 16 significant figures
    ... >> Java specifies IEEE 754-1985 representation for floating point. ... It specifies 53 bits of precision for doubles, ... one non-significant bit results in a value with two non-significant ... loss of any extended precision available to the hardware. ...
    (comp.lang.java.programmer)