Skip Menu |

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

Report information
The Basics
Id: 43694
Status: resolved
Priority: 0/
Queue: Math-BigInt
People
Owner: Nobody in particular
Requestors: emazep [...] gmail.com
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: 1.89
Fixed in: (no value)
Attachments
Math-BigInt-1.96-patch-id-43694.txt
perl-V.txt

History Show all quoted text
  Fri Feb 27 04:33:22 2009 emazep [...] gmail.com - Ticket created
Subject: The as_int() method on BigFloat objects loses precision on integers
The as_int() method on BigFloat objects loses precision even on integer values, while it shouldn't: perl -MMath::BigFloat -e 'print Math::BigFloat->new('1234567890987654321')->as_int, "\n"' # 1234567890987650000 Thanks for your invaluable work, Emanuele Zeppieri
Subject: perl-V.txt
Summary of my perl5 (revision 5 version 10 subversion 0 patch 34065) configuration: Platform: osname=cygwin, osvers=1.5.25(0.15642), archname=cygwin-thread-multi-64int uname='cygwin_nt-5.1 reini 1.5.25(0.15642) 2008-06-12 19:34 i686 cygwin ' config_args='-de -Dmksymlinks -Dusethreads -Dmad=y -Dusedevel' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-O3', cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using dmd 0.125)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags =' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat perllibs=-ldl -lcrypt libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY MYMALLOC PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MAD PERL_MALLOC_WRAP PERL_USE_SAFE_PUTENV USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Locally applied patches: MAINT34065 CYG11 no-bs CYG12 no archlib in otherlibdirs CYG14 Dynaloader CYG15 static-Win32CORE Bug#55162 File::Spec::case_tolerant performance Built under cygwin Compiled at Jun 30 2008 16:05:15 %ENV: CYGWIN="" @INC: /usr/lib/perl5/5.10/i686-cygwin /usr/lib/perl5/5.10 /usr/lib/perl5/site_perl/5.10/i686-cygwin /usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/vendor_perl/5.10/i686-cygwin /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .
  Tue Nov 02 10:46:07 2010 peter.john.acklam [...] gmail.com - Correspondence added
The problem can be traced to the second last line of the as_number() method in Math::BigFloat. The line is $z = Math::BigInt->new( $x->{sign} . $MBI->_num($z)); Before this line $z = [987654321, 234567890, 1] on my computer. It might be different on other computers, depending on $BASE, but it will be something equivalent. So far, so good. Now, $MBI->_num($z) returns the Perl scalar 1.23456789098765e+18, which is then used to construct a Math::BigInt object with the value 1234567890987650000. Clearly, using $MBI->_num($z) here is a mistake. I'm not really sure whether the main problem is in the code or the documentation. The name as_number() suggests that returning a Perl scalar is the right thing, whereas the name as_int() suggests that returning a Math::BigInt (or a Perl scalar integer) is the right thing. This bug is two years(!) old, so it's time to fix it. I don't have a patch yet, but I'll write one. In the meantime, it would be nice if the maintainers did some maintaining. I have written six patches over the last few weeks. So far I have not received any feedback on any of the patches from any of the maintainers. Has maintenance stalled?
  Tue Nov 02 10:46:07 2010 The RT System itself - Status changed from 'new' to 'open'
  Tue Nov 02 16:08:39 2010 peter.john.acklam [...] gmail.com - Correspondence added
This bug was introduced in version 1.70. In Math::BigFloat -> as_number() I changed _num() to _str(). The former returns a Perl scalar, but the latter returns a string, preserving all digits. I also added a test to confirms the correct behaviour. Patch included.
Subject: Math-BigInt-1.96-patch-id-43694.txt
diff -ur Math-BigInt-1.96-orig/lib/Math/BigFloat.pm Math-BigInt-1.96-patched-id-43694/lib/Math/BigFloat.pm --- Math-BigInt-1.96-orig/lib/Math/BigFloat.pm 2010-09-28 06:34:04.000000000 +0200 +++ Math-BigInt-1.96-patched-id-43694/lib/Math/BigFloat.pm 2010-11-02 21:01:44.171875000 +0100 @@ -3693,7 +3693,7 @@ { $MBI->_lsft( $z, $x->{_e},10); } - $z = Math::BigInt->new( $x->{sign} . $MBI->_num($z)); + $z = Math::BigInt->new( $x->{sign} . $MBI->_str($z)); $z; } diff -ur Math-BigInt-1.96-orig/t/bigfltpm.inc Math-BigInt-1.96-patched-id-43694/t/bigfltpm.inc --- Math-BigInt-1.96-orig/t/bigfltpm.inc 2010-09-13 16:28:42.000000000 +0200 +++ Math-BigInt-1.96-patched-id-43694/t/bigfltpm.inc 2010-11-02 20:26:02.968750000 +0100 @@ -587,6 +587,7 @@ -2:-2 -123.456:-123 -200:-200 +71243225429896467497217836789578596379:71243225429896467497217836789578596379 # test for bug in brsft() not handling cases that return 0 0.000641:0 0.0006412:0 diff -ur Math-BigInt-1.96-orig/t/bigfltpm.t Math-BigInt-1.96-patched-id-43694/t/bigfltpm.t --- Math-BigInt-1.96-orig/t/bigfltpm.t 2010-09-13 16:28:42.000000000 +0200 +++ Math-BigInt-1.96-patched-id-43694/t/bigfltpm.t 2010-11-02 21:02:18.453125000 +0100 @@ -1,7 +1,7 @@ #!/usr/bin/perl -w use strict; -use Test::More tests => 2316 +use Test::More tests => 2317 + 5; # own tests
  Tue Nov 02 16:28:31 2010 jonathan [...] leto.net - Correspondence added
CC: Florian Ragwitz <rafl [...] debian.org>
Subject: Re: [rt.cpan.org #43694] The as_int() method on BigFloat objects loses precision on integers
Date: Tue, 2 Nov 2010 13:28:08 -0700
To: bug-Math-BigInt [...] rt.cpan.org
From: Jonathan Leto <jonathan [...] leto.net>
Howdy Peter, Thanks for all of your bug reports recently. Maintenance hasn't stalled, but the current maintainers of these modules, myself included, don't have copious free time to hack on it. Perhaps you would like a commit bit on the relevant repos, so that we are not a bottleneck towards improving them? I definitely give you a +1 for a commit bit. Duke On Tue, Nov 2, 2010 at 7:46 AM, Peter John Acklam via RT <bug-Math-BigInt@rt.cpan.org> wrote: Show quoted text
>       Queue: Math-BigInt >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=43694 > > > The problem can be traced to the second last line of the as_number() > method in Math::BigFloat. The line is > >  $z = Math::BigInt->new( $x->{sign} . $MBI->_num($z)); > > Before this line $z = [987654321, 234567890, 1] on my computer. It might > be different on other computers, depending on $BASE, but it will be > something equivalent. So far, so good. > > Now, $MBI->_num($z) returns the Perl scalar 1.23456789098765e+18, which > is then used to construct a Math::BigInt object with the value > 1234567890987650000. Clearly, using $MBI->_num($z) here is a mistake. > > I'm not really sure whether the main problem is in the code or the > documentation. The name as_number() suggests that returning a Perl > scalar is the right thing, whereas the name as_int() suggests that > returning a Math::BigInt (or a Perl scalar integer) is the right thing. > > This bug is two years(!) old, so it's time to fix it. I don't have a > patch yet, but I'll write one. In the meantime, it would be nice if the > maintainers did some maintaining. I have written six patches over the > last few weeks. So far I have not received any feedback on any of the > patches from any of the maintainers. Has maintenance stalled? >
-- Jonathan "Duke" Leto jonathan@leto.net http://leto.net
  Tue Nov 02 17:56:01 2010 emazep [...] gmail.com - Correspondence added
Subject: Re: [rt.cpan.org #43694] The as_int() method on BigFloat objects loses precision on integers
Date: Tue, 02 Nov 2010 22:55:50 +0100
To: bug-Math-BigInt [...] rt.cpan.org
From: Emanuele Zeppieri <emazep [...] gmail.com>
On 2010-11-02 21:08, Peter John Acklam via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=43694> > > This bug was introduced in version 1.70. > > In Math::BigFloat -> as_number() I changed _num() to _str(). The former > returns a Perl scalar, but the latter returns a string, preserving all > digits. I also added a test to confirms the correct behaviour. > > Patch included.
It seems the correct solution also to me. Thank you very much Peter! -Emanuele
  Wed Nov 03 03:01:31 2010 peter.john.acklam [...] gmail.com - Correspondence added
RT-Send-CC: jonathan [...] leto.net, rafl [...] debian.org
If none of you have time to apply the patch(es), then I'll be happy to do it. When you say "+1 for a commit bit", are you referring to git://perl5.git.perl.org/perl.git or some other repo? Peter On Tue Nov 02 16:28:31 2010, LETO wrote: Show quoted text
> Howdy Peter, > > Thanks for all of your bug reports recently. Maintenance hasn't > stalled, but the current > maintainers of these modules, myself included, don't have copious free > time to hack > on it. Perhaps you would like a commit bit on the relevant repos, so > that we are not a > bottleneck towards improving them? > > I definitely give you a +1 for a commit bit. > > Duke
  Wed Nov 03 06:27:34 2010 rafl [...] debian.org - Correspondence added
CC: bug-Math-BigInt [...] rt.cpan.org, jonathan [...] leto.net
Subject: Re: [rt.cpan.org #43694] The as_int() method on BigFloat objects loses precision on integers
Date: Wed, 03 Nov 2010 11:26:25 +0100
To: pjacklam [...] online.no
From: Florian Ragwitz <rafl [...] debian.org>
"Peter John Acklam via RT" <bug-Math-BigInt@rt.cpan.org> writes: Show quoted text
> If none of you have time to apply the patch(es), then I'll be happy to > do it.
At least for me, it's not so much the applying, but the reviewing. However, reviewing would also be a whole lot easier if there was a git repository to just fetch from. Show quoted text
> When you say "+1 for a commit bit", are you referring to > git://perl5.git.perl.org/perl.git or some other repo?
Handing out commit bits to perl itself unfortunately isn't quite as easy as one would hope. However, There's repositories for all of the bigint stuff on github. They all live at http://github.com/rafl, for example http://github.com/rafl/Math-BigInt and http://github.com/rafl/Math-BigInt-FastCalc. Math-BigRat, the only exception, is at http://github.com/leto/Math-BigRat. While all the bigint modules actually have the perl core as their canonical upstream, I'll be happy to sync changes between the individual repositories for the CPAN versions and the core, like I've been doing in the past. If you want, you can get a commit bit for all of those so you can create branches for the individual issues you've been working on. Alternatively you can just click the Fork button on any of those repositories to get your own repository of them. I'd actually prefer the latter, as that requires the contributor to explicitly tell someone about his changes via private email, or githubs pull request, or whatever, so they can be pulled in - avoiding the problem of forgotten branches. However, I'll be happy to cope with whatever works for you.
Download (untitled)
application/pgp-signature 197b

Message body not shown because it is not plain text.

  Mon Nov 15 03:17:35 2010 rafl [...] debian.org - Status changed from 'open' to 'resolved'