bug in bigint?

blazar has asked for the wisdom of the Perl Monks concerning the following question:

Not a real problem for me, but by accidentally leaving a

use bigint;
[download]

line in some code that was not needing it anymore, I found that it triggers an error that can be reproduced by trying one of the examples found in perldoc bigint itself, namely:

$ perl -Mbigint -le 'print log(2)'
Can't use an undefined value as an ARRAY reference at /usr/lib/perl5/5
+.8.8/Math/BigInt/Calc.pm line 1338.
[download]

(I don't know if this is a possible bug in bigint itself or in Math::BigInt, and passing the 't' option to the former doesn't really help, see below)

$ perl -Mbigint=t -le 'print log(2)'                           MBI imp
+ort Math::BigInt::Trace :constant
MBI new '2' => '2' (Math::BigInt::Trace)
Can't use an undefined value as an ARRAY reference at /usr/lib/perl5/5
+.8.8/Math/BigInt/Calc.pm line 1338.
[download]

Just thought this may be interesting. Tested with 5.8.8 under both Linux and Windows.

Comment on bug in bigint? Select or Download Code

Replies are listed 'Best First'.
Re: bug in bigint? by shmem (Chancellor) on Dec 01, 2006 at 19:17 UTC
It's a bug in Math::BigInt. `log` is overloaded with `'log' => sub { $_[0]->copy()->blog($_[1]); },` [download] which returns just NaN with perl 5.8.0; there the routine reads `sub blog { # not implemented yet my ($self,$x,$base,$a,$p,$r) = ref($_[0]) ? (ref($_[0]),@_) : object +ify(1,@_); return $upgrade->blog($x,$base,$a,$p,$r) if defined $upgrade; return $x->bnan(); }` [download] In 5.8.8 the "not implemented" comment went away, but alas, there's still no base for blog to work with. `blog` calls _int_log `my ($rc,$exact) = $CALC->_log_int($x->{value},$base->{value});` [download] - but `$base->{value}` is just `undef` - `sub _log_int { # calculate integer log of $x to base $base # ref to array, ref to array - return ref to array my ($c,$x,$base) = @_; # X == 0 => NaN return if (scalar @$x == 1 && $x->[0] == 0); # BASE 0 or 1 => NaN return if (scalar @$base == 1 && $base->[0] < 2);` [download] - which names that value `$base` (poor practive imho to use a scalar named `$base` as a hash- and arrayref in different parts of the code) and tries to dereference it as an arrayref. Bummer. --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply] [d/l] [select]
Re: bug in bigint? by swampyankee (Parson) on Dec 01, 2006 at 18:04 UTC
I've poked through my copies of calc.pm and bigint.pm. The offending routine is _log_int (I'm sure you knew that) which requires 2 arguments (the number and the base to which the log is to be taken; I'm sure you knew that, too). It's called from blog in bigint.pm, without the second argument. I'd agree that this is a bug. I also noticed that `#!perl use strict; use warnings; use bignum; my $n = -1; print 10.00 *$n . "\n";` [download] returns NaN (on Windows; ) for negative values of $n. However, Math::BigFloat works. 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.	[reply] [d/l]
Re^2: bug in bigint? by blazar (Canon) on Dec 01, 2006 at 18:59 UTC
The offending routine is _log_int (I'm sure you knew that) which requires 2 arguments (the number and the base to which the log is to be taken; I'm sure you knew that, too). Actually you are wrong... being sure I knew. In fact I didn't. I suppose it would have been easy to know. But I wasn't extremely interested, just stumped into this, and felt like reporting. I was quite confident this may be a real bug of the module, for once (generally a perceived bug), but preferred discussing the issue here. I'll report it to the author as well.	[reply]