Skip Menu |

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

Report information
The Basics
Id: 110986
Status: open
Priority: 0/
Queue: Math-GMPz

People
Owner: Nobody in particular
Requestors: DANAJ [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.42
Fixed in: (no value)



Subject: Does not accept Math::BigInt objects as input
It would be convenient if Math::GMPz accepted Math::BigInt objects in new(), ideally including overloads. Math::BigInt is a standard Perl method for big integers, so is quite common. Math::GMPz is *much* faster both in operations but also overhead, so is nice to use when doing lots of operations. I suspect just stringifying the input is enough, so it works regardless of back end. But if you find a good non-brittle way to dig into the backend and optimize the Math::BigInt::GMP case, that would be awesome. $ perl -E 'use Math::GMPz; use Math::BigInt; my $n = Math::BigInt->new(10); my $m = Math::GMPz->new($n); say "$n $m";' Inappropriate argument supplied to new() at /Users/djacobsen/perl5/perlbrew/perls/perl-5.22.0/lib/site_perl/5.22.0/darwin-thread-multi-2level/Math/GMPz.pm line 197. For comparison: $ perl -E 'use Math::GMP; use Math::BigInt; my $n = Math::BigInt->new(10); my $m = Math::GMP->new($n); say "$n $m";' 10 10 $ perl -E 'use Math::Pari; use Math::BigInt; my $n = Math::BigInt->new(10); my $m = Math::Pari->new($n); say "$n $m";' 10 10 $ perl -E 'use Math::Int128 qw/int128/; use Math::BigInt; my $n = Math::BigInt->new(10); my $m = int128($n); say "$n $m";' 10 10
Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
Date: Fri, 8 Jan 2016 13:40:34 +1100
To: <bug-Math-GMPz [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: Dana Jacobsen via RT Sent: Friday, January 08, 2016 4:36 AM To: sisyphus1@optusnet.com.au Subject: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input Thu Jan 07 12:36:53 2016: Request 110986 was acted upon. Transaction: Ticket created by DANAJ Queue: Math-GMPz Subject: Does not accept Math::BigInt objects as input Broken in: 0.42 Severity: Wishlist Owner: Nobody Requestors: DANAJ@cpan.org Status: new Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110986 >
> It would be convenient if Math::GMPz accepted Math::BigInt objects in > new(), ideally including overloads.
Yes, I can do that.
> Math::BigInt is a standard Perl method for big integers, so is quite > common. Math::GMPz is *much* faster both in operations but also overhead, > so is nice to use when doing lots of operations. > > I suspect just stringifying the input is enough, so it works regardless of > back end.
For a purely perl Math::BigInt object, stringifying is about as good as one can do (AFAIK).
> But if you find a good non-brittle way to dig into the backend and > optimize the Math::BigInt::GMP case, that would be awesome.
If we're going to accommodate Math::BigInt objects then it would be nice to handle those that have the GMP backend as efficiently as we can ( .... despite the relative ease of simply implementing it via "stringification" :-) I'm assuming that Math::BigInt::GMP itself is quite resilient and reliable ? Based on Math::BigInt::GMP's mpz_from_sv_nofail() function (and associated #defines) I came up with the attached as a starting demo for getting access to the mpz_t that's in the Math::BigInt::GMP object that's in the Math::BigInt object. But, I'm a complete klutz when it comes to magic and I don't understand why, in that script, I have to comment out the #if GMP_HAS_MAGICEXT && mg->mg_virtual == &vtbl_gmp #endif that's in the original mpz_from_sv_nofail(). Probably a simple brainfart ... can you shed any light on what's going on there ? (It's no big deal if you can't shed any light on that ... I can always seek assistance from perlmonks or p5p.) If handling the Math::BigInt::GMP objects efficiently starts looking too involved, I'll just settle for stringifying *all* Math::BigInt objects - and work on improving the efficiency re the GMP-backended ones later. Cheers, Rob

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
Date: Fri, 8 Jan 2016 21:00:27 +1100
To: <bug-Math-GMPz [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: sisyphus1@optusnet.com.au via RT Sent: Friday, January 08, 2016 1:41 PM To: sisyphus1@optusnet.com.au Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
>> It would be convenient if Math::GMPz accepted Math::BigInt objects in >> new(), ideally including overloads.
> > Yes, I can do that.
An additional thought as I implement Math::BigInt overloads in Math::GMPz: Note that, wrt overloading of subtraction, Math::BigInt->new('42') - Math::GMPz->new('21') returns a Math::BigInt object, whereas Math::GMPz->new('42') - Math::BigInt->new('21') will return a Math::GMPz object - and similarly for the overloading of the "-" and "%" operators. Is that a concern for you ? It doesn't really bother me, though I think it's the sort of thing that can easily confuse users. I guess the same thing happens with Math::BigInt/Math::GMP, too. It also occurred to me that $z = Rmpz_init_set_str(Math::BigInt->new('123'), 10); is an existing alternative to $z = Math::GMPz->new(Math::BigInt->new('123')); In fact, you can pass any object to Rmpz_init_set_str() and it should do "the right thing" so long as the stringification of that object "does the right thing". Anyway .... just a couple of thoughts .... and they don't deter me from pushing on. Cheers, Rob
Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
Date: Sat, 9 Jan 2016 12:48:09 +1100
To: <bug-Math-GMPz [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: sisyphus1@optusnet.com.au via RT Sent: Friday, January 08, 2016 1:41 PM To: sisyphus1@optusnet.com.au Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
> Note that, wrt overloading of subtraction ..... and similarly for the > overloading of the "-" and "%" operators.
Not sure why I singled out the non-commutative operators when the commutative operators are, of course, affected in the same way. (Something to do with not thinking, I expect.) Not that it really belongs here, but I've set up things so that for a limited range of operations, an overloaded operation between a Math::MPFR object and a Math::GMPq/Math::GMPf/Math::GMPz returns a Math::MPFR object, irrespective of the order of the operands. From the Math::MPFR documentation: As of version 3.13 of Math::MPFR, some cross-class overloading is allowed. Let $M be a Math::MPFR object, and $G be any one of a Math::GMPz, Math::GMPq or Math::GMPf object. Then it is now permissible to do: $M + $G; $M - $G; $M * $G; $M / $G; $M ** $G; In each of the above, a Math::MPFR object containing the result of the operation is returned.It is also now permissible to do: $M += $G; $M -= $G; $M *= $G; $M /= $G; $M **= $G; If you have version 0.35 (or later) of Math::GMPz, Math::GMPq and Math::GMPf, it is also permissible to do: $G + $M; $G - $M; $G * $M; $G / $M; $G ** $M; Again, each of those operations returns a Math::MPFR object containing the result of the operation. Each operation is conducted using current default rounding mode.
Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
Date: Sat, 9 Jan 2016 15:58:18 +1100
To: <bug-Math-GMPz [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Queue: Math-GMPz Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110986 > Math::BigInt overloading now available from github. At this stage, the overloading (even for the Math::BigInt::GMP variant) is done by stringifying the Math::BigInt object. I plan to send it to CPAN tomorrow, but if anyone wants to test it out in the meantime: git clone git@github.com:sisyphus/math-gmpz Math-GMPz Cheers, Rob
Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
Date: Tue, 12 Jan 2016 01:00:57 +1100
To: <bug-Math-GMPz [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Queue: Math-GMPz Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110986 > The version at github (git clone git@github.com:sisyphus/math-gmpz Math-GMPz) now has enhanced Math::BigInt::GMP overloading that accesses the mpz_t directly, and therefore more efficiently. The robustness of this enhancement is yet to be established - though I've had no problem with it on perls ranging from 5.8.8 to 5.22.0 and on powerpc64 (running Debian Wheezy), Ubuntu and Windows. The enhanced approach can be switched off by commenting out the line $defines .= " -DENABLE_MATH_BIGINT_GMP_OVERLOAD"; in the Makefile.PL. If that is done, then the Math::BigInt::GMP overloading reverts to stringifying the Math::BigInt object, and then converting that string to an mpz_t using mpz_set_str. Cheers, Rob
Rob, As usual I'm impressed by your speed at solving these things. This sounds great. I haven't had time to test the github changes yet, but will try to get to it in the next couple days. Dana
Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
Date: Tue, 12 Jan 2016 14:37:38 +1100
To: <bug-Math-GMPz [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: Dana Jacobsen via RT Sent: Tuesday, January 12, 2016 2:12 AM To: sisyphus1@optusnet.com.au Subject: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
> I haven't had time to test the github changes yet, but will try to get to > it in the next couple days.
There's no hurry - I'm hanging back from pushing it to CPAN in case something comes out of http://www.perlmonks.org/?node_id=1152413 In the meantime I'll just upload improvements to the code on github as I become aware of them. Some nits to pick at: I'm not doing the "&& mg->mg_virtual == &vtbl_gmp" check that Math::BigInt::GMP does - and I wonder if/how that omission can lead to breakage of the Math::BigInt::GMP overloading. I'm also ignoring the "threadsafe" aspect that Math::BigInt::GMP apparently takes into account. The code assumes that Math::BigInt object has a key named "value" and a key named "sign" and that, if the "sign" key is neither "-" nor "+", then the Math::BigInt object is not valid for the purposes of GMP - in which case the overload sub croaks. (For all of the Math::BigInt objects I've looked at the "sign" key is neither "-" nor "+" whenn the Math::BigInt object is NaN/Inf.) If Math::BigInt::GMP overloading is in place but, for some reason, fails to set the mpz variable then it just falls through to overloading via stringification. This is good (in so far as the overloading still works) but not so good in that there's nothing to tell the user that this has happened. The mpz variable is currently declared as "mpz_t * mpz = (mpz_t*)NULL;" But at various points in the code I have to cast it to mpz_scrptr (or mpz_ptr in one place) to avoid compiler warnings. I don't really understand that, but I often get confused by pointers. (I think the "mpz_ptr" and "mpz_srcptr" types go back quite a long way in gmp - at least I see them in demos/perl/GMP.xs in the gmp source distro, and I don't think that code has been touched this century.) These nits aren't currently bothering me too much - I mainly just wanted you to be aware of them. Cheers, Rob
Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
Date: Wed, 13 Jan 2016 01:05:03 +1100
To: <bug-Math-GMPz [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Ooops ... handling of the sign needs fixing. I'll do that tomorrow. Cheers, Rob
Subject: Re: [rt.cpan.org #110986] Does not accept Math::BigInt objects as input
Date: Wed, 13 Jan 2016 14:43:15 +1100
To: <bug-Math-GMPz [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
> Ooops ... handling of the sign needs fixing. > I'll do that tomorrow.
new() and Math::BigInt::GMP overloading now fixed in github. Extra tests added. Cheers, Rob
Ran out of excuses for procrastinating further - Math-GMPz-0.43 now uploaded to CPAN. Cheers, Rob