Bug #80162 for Math-BigInt: Can no longer subtract an undefined value.

Sat Oct 13 02:02:21 2012 turtle [...] think-electric.com - Ticket created

Subject:

Can no longer subtract an undefined value.

As elegantly reported here: http://lists.opensuse.org/opensuse-bugs/2012-06/msg01204.html You can no longer subtract an undefined value. # perl -e 'use bigint; 5 + $x;' # perl -e 'use bigint; $x - 5;' # perl -e 'use bigint; 5 - $x;' Can't call method "is_zero" on an undefined value at /usr/lib/perl5/5.16.0/Math/BigInt.pm line 1200. I did a little experimenting of my own in BigInt.pm and by reverting only sub objectify to my previous version 1.993 The I narrowed it down to this tiny patch: --- BigInt-b.pm 2012-10-12 21:55:30.102263313 -0700 +++ BigInt.pm 2012-10-12 22:42:33.163394429 -0700 @@ -2669,9 +2669,9 @@ # Don't do anything with undefs. - unless (defined($a[$i])) { - next; - } + #unless (defined($a[$i])) { + # next; + #} # Perl scalars are fed to the appropriate constructor. Which then gives me perl -e 'use bigint; print 5 - $x;' 5 As expected. PS Thanks for your exelent work!

Thu Oct 31 15:37:30 2013 DANAJ [...] cpan.org - Correspondence added

How about this as an alternate, replacing the skip undefs: # Warn with undefs, but treat them as zero if (!defined ($a[$i]) && warnings::enabled('uninitialized')) { require Carp; Carp::carp ("Use of uninitialized value in Math::BigInt expression"); } This gives more similar behavior to the non-bigint case. Without warnings on, it should produce the same results (we turn undefs into zero). With warnings, it will produce the "Use of uninitialized value" warning and use zero, just like the non-bigint case. There are some situations where we don't get a warning, e.g. "say $x % 5". I think this is generally a better outcome than (1) different behavior from non-bigint (2) inconsistent behavior: $x % 5 works, but 5 % $x does not 5 ^ $x produces NaN and no warning/error, $x^5 produces 5 (3) screwy error messages, e.g.: Can't call method "is_zero" on an undefined value at ... Can't call method "is_nan" on unblessed reference at ...

Thu Oct 31 15:37:30 2013 The RT System itself - Status changed from 'new' to 'open'

Sun Nov 03 01:36:50 2013 turtle [...] think-electric.com - Correspondence added

Subject:	Re: [rt.cpan.org #80162] Can no longer subtract an undefined value.
Date:	Sat, 2 Nov 2013 22:36:37 -0700
To:	bug-Math-BigInt [...] rt.cpan.org
From:	turtle [...] think-electric.com

Excellent I approve Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=80162 > > > How about this as an alternate, replacing the skip undefs: > > # Warn with undefs, but treat them as zero > if (!defined ($a[$i]) && warnings::enabled('uninitialized')) { > require Carp; > Carp::carp ("Use of uninitialized value in Math::BigInt > expression"); > } > > This gives more similar behavior to the non-bigint case. Without warnings > on, it should produce the same results (we turn undefs into zero). With > warnings, it will produce the "Use of uninitialized value" warning and use > zero, just like the non-bigint case. > > There are some situations where we don't get a warning, e.g. "say $x % 5". > > I think this is generally a better outcome than > > (1) different behavior from non-bigint > > (2) inconsistent behavior: > $x % 5 works, but 5 % $x does not > 5 ^ $x produces NaN and no warning/error, $x^5 produces 5 > > (3) screwy error messages, e.g.: > Can't call method "is_zero" on an undefined value at ... > Can't call method "is_nan" on unblessed reference at ... >

Mon Aug 17 07:08:27 2015 peter.john.acklam [...] gmail.com - Correspondence added

This patch will give a warning when executing something like the following, which computes the logarithm of 2 in the default base (Euler's constant) and rounds the result to 8 digits: $ perl -MMath::BigFloat -wle 'print Math::BigFloat -> new("2") -> blog(undef, 8)' 0.69314718 The problem is that Math::Big(Int|Float) and big(int|num) have differing semantics, and one can not make Math::BigInt::objectify() handle both. I think we have to come up with a different solution to this problem. The first that pops into my mind is to handle this though use of the "overload" package in big(int|num).

Sun Aug 30 08:40:23 2015 peter.john.acklam [...] gmail.com - Correspondence added

I have looked further into this, and it seems like changes need to be made in the new() methods of Math::BigInt, Math::BigFloat, Math::BigRat, and Math::BigInt::Lite to get the same semantics as core Perl. I'm not yet sure whether the best solution is to use a config() option or to introduce a subclass for each of the above.

Wed Sep 23 08:25:11 2015 peter.john.acklam [...] gmail.com - Correspondence added

From what I can tell, this was fixed in Math-BigInt-1.9995. If you are able to reproduce this bug, please let me know which version of the distributions Math-BigInt and bignum that are affected.

Wed Sep 23 12:26:56 2015 turtle [...] think-electric.com - Correspondence added

Subject:	Re: [rt.cpan.org #80162] Can no longer subtract an undefined value.
Date:	Wed, 23 Sep 2015 09:26:46 -0700
To:	bug-Math-BigInt [...] rt.cpan.org
From:	Stephen Schmiechen <turtle [...] think-electric.com>

Yes it is fixed the bug should be closed thank you! On Wed, Sep 23, 2015 at 5:25 AM, Peter John Acklam via RT <bug-Math-BigInt@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=80162 > > > From what I can tell, this was fixed in Math-BigInt-1.9995. If you are able to reproduce this bug, please let me know which version of the distributions Math-BigInt and bignum that are affected.

Wed Jan 06 03:26:18 2016 peter.john.acklam [...] gmail.com - Correspondence added

Fixed in v1.9995

Wed Jan 06 03:26:20 2016 peter.john.acklam [...] gmail.com - Status changed from 'open' to 'resolved'

Wed Jan 06 03:26:21 2016 peter.john.acklam [...] gmail.com - Fixed in 1.9995 added

Wed Jan 06 03:26:21 2016 peter.john.acklam [...] gmail.com - Fixed in 1.93 deleted