Skip Menu |

This queue is for tickets about the Math-BigInt-Lite CPAN distribution.

Report information
The Basics
Id: 121284
Status: open
Priority: 0/
Queue: Math-BigInt-Lite

Owner: Nobody in particular
Requestors: DANAJ [...]

Bug Information
Severity: (no value)
Broken in: 0.17
Fixed in: (no value)

Subject: Problems with Math::BigInt gcd
Download (untitled) / with headers
text/plain 251b
After installing Math::BigInt::Lite, the following: perl -E 'use bigint; ($a,$b)=(8267,927208363107752634625923); say Math::BigInt::bgcd($a,$b);' instead of producing 1, now does: Can't use an undefined value as an ARRAY reference at ....
Download (untitled) / with headers
text/plain 139b
Thanks for the report. This is yet another case where the broken OO design in the Math::BigInt-related modules shows up. I'll look into it.
Download (untitled) / with headers
text/plain 1.4k
It appears that this is a very old bug. Behind the scenes, the original one-liner is equivalent to this: ---------------- use strict; use warnings; use 5.014; use Math::BigInt; use Math::BigInt::Lite; my $a = Math::BigInt::Lite -> new(8267); my $b = Math::BigInt -> new(927208363107752634625923); say Math::BigInt::bgcd($a, $b); ---------------- Math::BigInt::bgcd() first uses objectify() to ensure that all operands are objects() of the desired ("goal") class. In this case, objectify() is not given a desired class explicitly, so it assumes that the desired class is the class of the first operand, which is Math::BigInt::Lite. objectify() sets out to convert all the operands to Math::BigInt::Lite objects, but it accepts objects of classes that Math::BigInt::Lite may be upgraded to, i.e., Math::BigInt. The operand $a already is a Math::BigInt::Lite, and $b is a Math::BigInt, so objectify() does nothing to any of the operands. The operands are then passed back to Math::BigInt::bgcd(). So Math::BigInt::bgcd() is given a Math::BigInt::Lite ($a) and a Math::BigInt ($b), but Math::BigInt::bgcd() can't handle Math::BigInt::Lite objects, so the code fails. The solution seems to be to improve objectify() so it becomes better at guessing what the desired class is. One solution might be to use caller() to determine who called objectify(). A better solution, in my opinion, also happens to be a goal of of mine: to change all calls to objectify() into methods calls. That way, objectify() always knows the desired class.
Download (untitled) / with headers
text/plain 478b
Thanks for the detailed analysis! On Mon Apr 24 14:32:07 2017, pjacklam wrote: Show quoted text
> The solution seems to be to improve objectify() so it becomes better > at guessing what the desired class is.
This might be hard, as the same problem happens with blcm, and the theoretically best class would be different for the same arguments here. We don't know if ::Lite or not is best until we get the result back (since it could be either small or large). Just something to keep in mind.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to