-----BEGIN PGP SIGNED MESSAGE-----

Moin,

I got a bugreport from Dennis Boylan:

# perl -Mbigint -le 'print cos(4)'

Operation `cos': no method found, argument in overloaded package Math::BigInt

at -e line 1.

He reported that it works on some machine (older Perl, older BigInt, older GD

module) but no longer on the newer one. In my tests I think it never works

regardless of Perl or BigInt version, and it only worked for him because the

older GD (or GD::Piechart or something) didn't use cos() or used it

differently.

Now, there is an easy "fix", add the following lines to the overload section

of BigInt:

'cos' => sub { cos($_[0]->numify()) },

'sin' => sub { sin($_[0]->numify()) },

This would produce:

# perl -Ilib -Mbigint -le 'print sin(4)'

-0.756802495307928

However, to be consistent with the rest, it should really calculate:

* an integer result if in BigInt

* a float to arbitrary precision if in BigFloat

* a float if under "bignum" and a BigInt is passed

However, the catch is: BigInt/BigFloat don't know about cos()/sin(). The

module that can do this is Math::Big, not part of the core, and maybe not

even installed. Two options:

* include the code from Math::Big in BigInt/BigFloat (with suitable speedup

by putting it into Calc.pm)

* require Math::Big as in:

'cos' => sub {

require Math::Big;

return Math::Big::cos($_[0], ref($_[0])->accuracy());

},

The latter option produces:

# perl -Ilib -Mbigint -le 'print cos(2)'

-0.416146836547142386997568229500762189766001

# perl -Ilib -Mbigint=a,50 -le 'print cos(2)'

-0.41614683654714238699756822950076218976600077107554

Of course, that is not "right", because BigInt should return a truncated int()

as it does for sqrt() etc, and BigFloat should return the full result, and if

under bignum, BigInt should upgrade.

However, the critical question is:

Should BigInt duplicate/take ransom the code from Math::Big? Or should it

simple "require Math::Big" (with suitable error message if not found)?

Of course, this also poses the question of tan(), arctan(), and all the other

nastity stuff, along of the question of pi(), euler() etc. Ugh. Math::Big is

certainly not small (no pun intended).

Best wishes,

Tels

- --

Signed on Sat Oct 25 21:14:38 2003 with key 0x93B84C15.

Visit my photo gallery at http://bloodgate.com/photos/

PGP key on http://bloodgate.com/tels.asc or per email.

"We have problems like this all of the time," Kirk said, trying to

reassure me. "Sometimes its really hard to get things burning." --

http://tinyurl.com/qmg5

Moin,

I got a bugreport from Dennis Boylan:

# perl -Mbigint -le 'print cos(4)'

Operation `cos': no method found, argument in overloaded package Math::BigInt

at -e line 1.

He reported that it works on some machine (older Perl, older BigInt, older GD

module) but no longer on the newer one. In my tests I think it never works

regardless of Perl or BigInt version, and it only worked for him because the

older GD (or GD::Piechart or something) didn't use cos() or used it

differently.

Now, there is an easy "fix", add the following lines to the overload section

of BigInt:

'cos' => sub { cos($_[0]->numify()) },

'sin' => sub { sin($_[0]->numify()) },

This would produce:

# perl -Ilib -Mbigint -le 'print sin(4)'

-0.756802495307928

However, to be consistent with the rest, it should really calculate:

* an integer result if in BigInt

* a float to arbitrary precision if in BigFloat

* a float if under "bignum" and a BigInt is passed

However, the catch is: BigInt/BigFloat don't know about cos()/sin(). The

module that can do this is Math::Big, not part of the core, and maybe not

even installed. Two options:

* include the code from Math::Big in BigInt/BigFloat (with suitable speedup

by putting it into Calc.pm)

* require Math::Big as in:

'cos' => sub {

require Math::Big;

return Math::Big::cos($_[0], ref($_[0])->accuracy());

},

The latter option produces:

# perl -Ilib -Mbigint -le 'print cos(2)'

-0.416146836547142386997568229500762189766001

# perl -Ilib -Mbigint=a,50 -le 'print cos(2)'

-0.41614683654714238699756822950076218976600077107554

Of course, that is not "right", because BigInt should return a truncated int()

as it does for sqrt() etc, and BigFloat should return the full result, and if

under bignum, BigInt should upgrade.

However, the critical question is:

Should BigInt duplicate/take ransom the code from Math::Big? Or should it

simple "require Math::Big" (with suitable error message if not found)?

Of course, this also poses the question of tan(), arctan(), and all the other

nastity stuff, along of the question of pi(), euler() etc. Ugh. Math::Big is

certainly not small (no pun intended).

Best wishes,

Tels

- --

Signed on Sat Oct 25 21:14:38 2003 with key 0x93B84C15.

Visit my photo gallery at http://bloodgate.com/photos/

PGP key on http://bloodgate.com/tels.asc or per email.

"We have problems like this all of the time," Kirk said, trying to

reassure me. "Sometimes its really hard to get things burning." --

http://tinyurl.com/qmg5