bignum incompatible with looks_like_number() ???

Apparently, "use bignum;" causes problems with looks_like_number.

Background:

My code makes a call to Finance::Math:IRR to compute an Internal Rate of
return.

my call looks like this:
$result = xirr(%HashOfDatesAndCashflows, precision => 0.000001);

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

So, in my main .pl file, I added the line:
use bignum;

Which resulted in an error message:
ERROR: precision is not a valid number at /Users/cb/main.pl line 189

After digging around, I discovered that Finance::Math::IRR calls
looks_like_number($x) where $x is set to the value of the precision hash
key.

Sure enough, the debugger reveals that I'm calling xirr with:
         
'precision' => bless( {
                    '_m' => [1],
                        '_es' => '-',
                        '_e' => [6],
                        'sign' => '+'
                       }, 'Math::BigFloat' )

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

I can't believe two such frequently-used components are incompatible.

bignyum is included in most Perl builds.

looks_like_number() is part of the perl api according to
http://search.cpan.org/~nwclark/perl-5.8.8/pod/perlapi.pod


What am I doing wrong?

I'm using Perl 5.8.6 under MacOS Darwin

Thanks
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
=----

----== 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 =----

Re: bignum incompatible with looks_like_number() ???

"C B" wrote in message
news:cb0-1D13A6.09170627062007@news.newsfeeds.com...
..
..
>
> my call looks like this:
> $result = xirr(%HashOfDatesAndCashflows, precision => 0.000001);
>
> This works fine, except that I'm getting answers that are a little off
> numerically.

That would probably be 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).

>
> So, in my main .pl file, I added the line:
> use bignum;
>
> Which resulted in an error message:
> ERROR: precision is not a valid number at /Users/cb/main.pl line 189
>
> After digging around, I discovered that Finance::Math::IRR calls
> looks_like_number($x) where $x is set to the value of the precision hash
> key.
>
> Sure enough, the debugger reveals that I'm calling xirr with:
>
> 'precision' => bless( {
> '_m' => [1],
> '_es' => '-',
> '_e' => [6],
> 'sign' => '+'
> }, 'Math::BigFloat' )
>
> 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().

I guess the basic issue is that Math::Finance::IRR is not built to handle
Math::BigFloat objects.

Cheers,
Rob

Re: bignum incompatible with looks_like_number() ???

In article <4681d0e6$0$8915$afc38c87@news.optusnet.com.au>,
"Sisyphus" 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 =----

Re: bignum incompatible with looks_like_number() ???

"C B" wrote in message
news:cb0-216FFD.15021027062007@news.newsfeeds.com...
..
..
>> 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

Re: bignum incompatible with looks_like_number() ???

Here's what I found out after digging into this issue:

1. bignum is intended to be fully compatible with looks_like_number()
and with all other arithmetical functions and operators.

2. If you try, for example,
$x = 2**512 + 0.1;
and you get an overflow or similar error, then inserting the single line:
use bignum;
into your Perl program should automagically extend the precision of all
calculations to whatever they need to be to get a useful result. In
keeping with the Perl philosophy, there are no arbitrary Perl-imposed
limits on how far you can take this --- you can go as far as memory and
other external constraints permit.

3. These statements apply to Perl 5 (there's a similar capability is in
Perl 6, but I believe it's invoked differently).

4. These statements fairly represent the _intent_ of the developers of
Bignum and its friends BigInt and BigFloat. There are, however, several
problem cases and boundary issues associated with overloading operators
like + and / and things like initialization constants. The situation
with XIRR that I described in my original post was such a case ---
is_a_number() incorrectly failed when it was called on an integer under
use bignum;

However, running exactly the same code under newer versions of certain
modules made the original problem go away.

5. If you decide to try
use bignum;
and it fails, you will be doing your fellow Perl users a good deed by
investigating the problem and helping the developers fix it.

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 =----

Re: bignum incompatible with looks_like_number() ???

"C B" wrote in message
news:cb0-A748E4.20291528062007@host-091-097-119-038.ewe-ip-b ackbone.de...
> Here's what I found out after digging into this issue:
>
> 1. bignum is intended to be fully compatible with looks_like_number()

Where did you find that ?

Cheers,
Rob

Re: bignum incompatible with looks_like_number() ???

In article <4683d775$0$13997$afc38c87@news.optusnet.com.au>,
"Sisyphus" wrote:

> > Here's what I found out after digging into this issue:
> > 1. bignum is intended to be fully compatible with looks_like_number()

> Where did you find that ?

Well, I started by reading this carefully:
http://perldoc.perl.org/bignum.html

Then I found a bunch of stuff like this:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=27606

Is there really any question as to the intent here?

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 =----

Re: bignum incompatible with looks_like_number() ???

"C B" wrote in message
news:cb0-0DBFAF.08135629062007@news.newsfeeds.com...
..
..
>
> Well, I started by reading this carefully:
> http://perldoc.perl.org/bignum.html

As it says:
------------------------------------
If you do
use bignum;

at the top of your script, Math::BigFloat and Math::BigInt will be loaded
and any constant number will be converted to an object (Math::BigFloat for
floats like 3.1415 and Math::BigInt for integers like 1234).
------------------------------------

That's about all it does, all it ever has does, and all it ever will do.

It's just a convenient way of working with the Math::Big* modules. It
doesn't mean that perl has suddenly been transformed into something that
natively handles numbers with magically-extended precision. If you want the
extended precision you still have to stay within the realm of the Math::Big*
modules - or you can use other packages that provided extended precision
(Math::Pari, Math::GMP, Math::MPFR, etc.)

There's no mention of 'looks_like_number' anywhere on that page.

>
> Then I found a bunch of stuff like this:
> http://rt.perl.org/rt3//Public/Bug/Display.html?id=27606
>

That's just a discussion of a bug in looks_like_number() - whereby
looks_like_number(undef) returned true. I don't see the relevance of that in
the context of this thread. The bug is fixed in perl 5.8.8 (and perhaps
earlier - I haven't checked).

Cheers,
Rob

Cheers,
Rob

Re: bignum incompatible with looks_like_number() ???

In article <4684f46f$0$30511$afc38c87@news.optusnet.com.au>,
"Sisyphus" wrote:

> > Well, I started by reading this carefully:
> > http://perldoc.perl.org/bignum.html
>
> As it says:
> ------------------------------------
> If you do
> use bignum;
>
> at the top of your script, Math::BigFloat and Math::BigInt will be loaded
> and any constant number will be converted to an object (Math::BigFloat for
> floats like 3.1415 and Math::BigInt for integers like 1234).
> ------------------------------------
>
> That's about all it does, all it ever has does, and all it ever will do.
>
> It's just a convenient way of working with the Math::Big* modules. It
> doesn't mean that perl has suddenly been transformed into something that
> natively handles numbers with magically-extended precision. If you want the
> extended precision you still have to stay within the realm of the Math::Big*
> modules - or you can use other packages that provided extended precision
> (Math::Pari, Math::GMP, Math::MPFR, etc.)
>
> There's no mention of 'looks_like_number' anywhere on that page.
>
> >
> > Then I found a bunch of stuff like this:
> > http://rt.perl.org/rt3//Public/Bug/Display.html?id=27606
> >
>
> That's just a discussion of a bug in looks_like_number() - whereby
> looks_like_number(undef) returned true. I don't see the relevance of that in
> the context of this thread. The bug is fixed in perl 5.8.8 (and perhaps
> earlier - I haven't checked).

Sisyphus, you have chosen your handle well.

Please give some examples of how you imagine bignum is SUPPOSED to be
used.

Please include $x = 2**512+0.0 in your examples.

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 =----

Re: bignum incompatible with looks_like_number() ???

"C B" wrote in message
news:cb0-AF4183.10300930062007@news.newsfeeds.com...
..
..
>
> Please give some examples of how you imagine bignum is SUPPOSED to be
> used.
>
> Please include $x = 2**512+0.0 in your examples.
>

I don't find any problem with the above example - though I believe there
might have been problems in the past when you tried to do that. If that was
a problem at one stage, it now seems to have been fixed - if you add a
fraction to Math::BigInt object that was created by bignum, then the
Math::BigInt object is first converted to a Math::BigFloat object, so that
the addition can take place. (Of course, if you're adding 0.0, bignum now
recognises that the Math::BigInt object can stay as a Math::BigInt object,
and 0 is simply added ... again I've a notion that bignum wasn't always that
clever in the past.)

It has just occurred to me that in concentrating on this 'looks_like_number'
compatibility, I've overlooked the possibility that if you remove the
looks_like_number() stipulations from the code in Finance::Math::IRR, then
it may well do exactly what you want anyway ... without the need to make any
other amendments. Probably worth testing (if you haven't already).

Consider Foo.pm:
-------------------------------
package Foo;
use Scalar::Util qw(looks_like_number);

sub my_foo {
my $out = $_[0] + 1;
return $out;
}

sub my_bar {
die "Not a number" unless(looks_like_number($_[0]));
my $out = $_[0] + 1;
return $out;
}

1;
-------------------------------

And try.pl:
-------------------------------
use strict;
use warnings;
use bignum;
use Foo;

my $x = (2 ** 512) + 0.0;
print ref($x), "\n";
print $x, "\n";
print Foo::my_foo(2 ** 512), "\n";
print Foo::my_bar(2 ** 512), "\n";
-------------------------------

Foo::my_bar dies because the argument did not look like a number .... but if
you remove that stipulation then there's no problem at all - Foo::my_bar()
is quite capable of dealing with bignum objects despite the
'looks_like_number' red herring.

So the question is:
When Finance::Math::IRR stipulates that the argument has to look like a
number, is that, too a red herring ? Or does Finance::Math::IRR have sound
reasons for stipulating that the argument must look like a number ?

(Ok ... that might be 2 questions :-)

Btw, when I run the above script (try.pl) I get:
----------------------------------
Math::BigInt
134078079299425970995740249982058461274793658205923933777235 61443721764030073546
976801874298166903427690031858186486050853753882811946569946 433649006084096
134078079299425970995740249982058461274793658205923933777235 61443721764030073546
976801874298166903427690031858186486050853753882811946569946 433649006084097
Not a number at Foo.pm line 10.
----------------------------------

Cheers,
Rob

Re: bignum incompatible with looks_like_number() ???

In article <468603ae$0$14626$afc38c87@news.optusnet.com.au>,
"Sisyphus" wrote:

> > Please give some examples of how you imagine bignum is SUPPOSED to be
> > used.
>
> > Please include $x = 2**512+0.0 in your examples.
> >

>
> Consider Foo.pm:
> -------------------------------
> package Foo;
> use Scalar::Util qw(looks_like_number);
>
> sub my_foo {
> my $out = $_[0] + 1;
> return $out;
> }
>
> sub my_bar {
> die "Not a number" unless(looks_like_number($_[0]));
> my $out = $_[0] + 1;
> return $out;
> }
>
> 1;
> -------------------------------
>
> And try.pl:
> -------------------------------
> use strict;
> use warnings;
> use bignum;
> use Foo;
>
> my $x = (2 ** 512) + 0.0;
> print ref($x), "\n";
> print $x, "\n";
> print Foo::my_foo(2 ** 512), "\n";
> print Foo::my_bar(2 ** 512), "\n";
> -------------------------------
>
>when I run the above script (try.pl) I get:
> ----------------------------------
> Math::BigInt
> 134078079299425970995740249982058461274793658205923933777235 614437217640300735
> 46
> 976801874298166903427690031858186486050853753882811946569946 433649006084096
> 134078079299425970995740249982058461274793658205923933777235 614437217640300735
> 46
> 976801874298166903427690031858186486050853753882811946569946 433649006084097
> Not a number at Foo.pm line 10.
> ----------------------------------

Leaving Foo.pm completely untouched, and changing try.pl to:

use strict;
use warnings;
#use bignum;
use Foo;

my $x =42;

print $x, "\n";
print Foo::my_foo(42), "\n";
print Foo::my_bar(42), "\n";

yields:
perl -I~ ~/test.pl
42
43
43

But removing the comment marker from in front of bignum causes the death.

See my subsequent post.

----== 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 =----

Suspended: bignum incompatible with looks_like_number() ???

Quick summary for those whose patience is exhausted:

perl -le 'print 2**512+0.01'
1.34078079299426e+154

perl -Mbignum -le 'print 2**512+0.01'
134078079299425970995740249982058461274793658205923933777235 6144372176403
007354697680187429816690342769003185818648605085375388281194 6569946433649
006084096.01


Warning: only read the following if you can tolerate the sort of
meandering argument that's been a feature of this thread this far...

I maintain that the function looks_like_number() should return 1 when
use bignum; is in effect. No other interpretations of the documentation
are credible.

There are others in this thread who apparently disagree (although their
actual opinion is difficult to discern).

It is certain that under some versions/configs looks_like_number()
returns 1 when passed a bignum.

In other cases it fails. I am trying to figure out exactly when and
why, and will post back to this thread when I know.

Until then, over and out.

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 =----

Re: Suspended: bignum incompatible with looks_like_number() ???

C B wrote:
> Quick summary for those whose patience is exhausted:
>
> perl -le 'print 2**512+0.01'
> 1.34078079299426e+154
>
> perl -Mbignum -le 'print 2**512+0.01'
> 134078079299425970995740249982058461274793658205923933777235 6144372176403
> 007354697680187429816690342769003185818648605085375388281194 6569946433649
> 006084096.01
>
> Warning: only read the following if you can tolerate the sort of
> meandering argument that's been a feature of this thread this far...
>
> I maintain that the function looks_like_number() should return 1 when
> use bignum; is in effect.

It would be nice, but it is nothing for you to have a hissy fit over.

> No other interpretations of the documentation
> are credible.

Wrong. No interpretation of the documentation could reasonably be taking
as a guarantee that the two need to play nice together. No part of the
documentation for either of these features mentions the other feature.
Indeed, from perlapi:

looks_like_number
Test if the content of an SV looks like a number
(or is a number).

Since an object created bignum is not the contents of an SV, (it is
contained in a HV blessed into Math::BigInt or Math::BigFloat, I think)
it is highly unlikely that looks_like_number was ever meant to work on
anything other ordinary SVs containing ordinary native format numbers (or
special tokens like inf)

Indeed, the very fact that it is located in the perlapi section suggests
that this is something that takes place mostly at the C level and not the
Perl level, and thus has limitations you would expect of C.

> There are others in this thread who apparently disagree (although their
> actual opinion is difficult to discern).

You are being an ass. Is that opinion clear enough for you?

>
> It is certain that under some versions/configs looks_like_number()
> returns 1 when passed a bignum.

I am not certain of that. Which versions/configs behave that way? What
example did you use?

> In other cases it fails. I am trying to figure out exactly when and
> why, and will post back to this thread when I know.

There is really nothing to figure out.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: Suspended: bignum incompatible with looks_like_number() ???

wrote in message
news:20070630190736.896$oA@newsreader.com...
..
..
>> I maintain that the function looks_like_number() should return 1 when
>> use bignum; is in effect.
>
> It would be nice, but it is nothing for you to have a hissy fit over.
>

I think I'd prefer that looks_like_number() limits itself to returning true
if and only if the particular scalar actually *does* look like a number :-)

I imagine that changing it could break all sorts of things -
Finance::Math::IRR for a start (apparently) - though, afaict, that still
remains untested. Faik, Finance::Math::IRR already works fine with bignum
objects - and the existing code (in IRR.pm):

if (!defined $precision || !looks_like_number($precision)) {

simply needs to be changed to something like:

if (!defined $precision || (!looks_like_number($precision) &&
ref($precision) ne 'Math::BigFloat')) {

I can't be bothered checking that out .... and it's unclear to me whether
the op has tested it.

Cheers,
Rob