|
Posted by Sisyphus on June 27, 2007, 5:15 am
Please log in for more thread options
.
.
>> 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.
>
Well ... *I* certainly don't brag about that ... and I don't think Larry
does, either.
As it stands, 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.
If that's not enough, then you (or someone else) will have to rewrite
Financial::Math::IRR so that it does accommodate the precision you need.
(And one way to do that would be to rewrite it so that it does work with
bignum objects.)
>> >
>> > 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.
AFAICT, it's the way things are. Whether it's out of line or not, I wouldn't
know - I'm not a philosopher.
>
> 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.
I believe it's also the decimal integer 1078530000 expressed in hex.
>
> 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 Scalar::Util::looks_like_number (which just wraps the perlapi function of
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.
Seems to me you're suggesting that perl should be able to seamlessly handle
numbers of whatever you precision you choose. I've no problem with that
suggestion - but it's not the way things are. Perl will natively and
seamlessly handle precision only up to the precision of the NV - usually the
same as a C double, but as much as a C long double (if perl was built that
way).
If you want to go beyond the precision provided, then you need packages such
as bignum, and you need modules that support those packages.
Maybe someone needs to write Financial::Math::IRR::BigFloat.
Cheers,
Rob
| 
XML Sitemap