Skip Menu |

This queue is for tickets about the bignum CPAN distribution.

Report information
The Basics
Id: 68129
Status: open
Priority: 0/
Queue: bignum

People
Owner: Nobody in particular
Requestors: pause [...] tlinx.org
Cc:
AdminCc:

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



Documentation for bignum is confusing or wrong. Says: EXAMPLES Some cool command line examples to impress the Python crowd ;) You might want to compare them to the results under -Mbignum or -Mbigrat: perl -Mbigint -le 'print sqrt(33)' perl -Mbigint -le 'print 2*255' perl -Mbigint -le 'print 4.5+2*255' perl -Mbigint -le 'print 3/7 + 5/7 + 8/3' perl -Mbigint -le 'print 123->is_odd()' perl -Mbigint -le 'print log(2)' perl -Mbigint -le 'print 2 ** 0.5' perl -Mbigint=a,65 -le 'print 2 ** 0.2' perl -Mbignum=a,65,l,GMP -le 'print 7 ** 7777' I run these and get: Show quoted text
> perl -Mbigint -le 'print sqrt(33)'
5 Show quoted text
> perl -Mbigint -le 'print 2*255'
510 Show quoted text
> perl -Mbigint -le 'print 4.5+2*255'
514 Show quoted text
> perl -Mbigint -le 'print 3/7 + 5/7 + 8/3'
2 Show quoted text
> perl -Mbigint -le 'print 123->is_odd()'
1 Show quoted text
> perl -Mbigint -le 'print log(2)'
0 Show quoted text
> perl -Mbigint -le 'print 2 ** 0.5'
1 Show quoted text
> perl -Mbigint=a,65 -le 'print 2 ** 0.2'
1 Show quoted text
> perl -Mbignum=a,65,l,GMP -le 'print 7 ** 7777'
"l" is not exported by the bignum module Can't continue after import errors at /usr/lib/perl5/5.10.0/bignum.pm line 232 BEGIN failed--compilation aborted. How are any of these 'impressive?' 2*255 = 510? Wow! 510+4.5=514? Isn't this the same as "use integer"? "l" is not exported? I don't see anything impressive about these examples. They don't demonstrate big integers at all from what I can see. Note it says to compare with using bigrat -- so I tried that as well: perl -Mbigrat -le 'print sqrt(33)' Segmentation fault (core dumped) The python folks will be overwhelmed! My perl -V: Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.6.31, archname=x86_64-linux-thread-multi uname='linux build35 2.6.31 #1 smp 2010-01-06 16:07:25 +0100 x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -DEBUGGING=both -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe' ccversion='', gccversion='4.4.1 [gcc-4_4-branch revision 150839]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.10.1.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.10.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_TRACK_MEMPOOL PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Sep 16 2010 16:21:22 @INC: /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl
RT-Send-CC: nospam-abuse [...] bloodgate.com
On Wed May 11 23:50:40 2011, LAWALSH wrote: Show quoted text
> Documentation for bignum is confusing or wrong. > > perl -Mbigint -le 'print sqrt(33)'
Are you really sure that is the documentation in bignum-0.25? Mine says (note "bignum", not "bigint"): perl -Mbignum -le 'print sqrt(33)' which works just fine: $ perl -Mbignum -le 'print sqrt(33)' 5.74456264653802865985061146821892931822 Show quoted text
> perl -Mbigrat -le 'print 3/7 + 5/7 + 8/3'
This should be using "bigrat", not "bigint": $ perl -Mbigrat -le 'print 3/7 + 5/7 + 8/3' 80/21 Show quoted text
> perl -Mbignum=a,65,l,GMP -le 'print 7 ** 7777'
Now that is indeed an error in the documentation. It should be perl -Mbignum=l,GMP -le 'print 7 ** 7777' Using "bigint" here would be fine too, since the output is an integer. Show quoted text
> How are any of these 'impressive?'
I see your point. The code and documentations of the Math-Bigint, Math-BigRat, and bignum have had lots of bugs and design flaws. Some are fixed, but there is still things left to do. Show quoted text
> Note it says to compare with using bigrat -- so I tried that as well: > perl -Mbigrat -le 'print sqrt(33)' > Segmentation fault (core dumped)
This happened with earlier versions of the Math-BigInt distribution, but should have been fixed by now. Which version of the Math-BigInt distribution are you using?
Subject: Re: [rt.cpan.org #68129]
Date: Sat, 14 May 2011 05:58:36 -0400
To: bug-bignum [...] rt.cpan.org
From: "Tels" <nospam-abuse [...] bloodgate.com>
I know one shouldn't (have to) defend one self, but: On Wed, May 11, 2011 11:50 pm, Linda A Walsh via RT wrote: Show quoted text
> Wed May 11 23:50:40 2011: Request 68129 was acted upon. > Transaction: Ticket created by LAWALSH > Queue: bignum > Subject: (No subject given) > Broken in: 0.25 > Severity: (no value) > Owner: Nobody > Requestors: pause@tlinx.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=68129 >
Show quoted text
> Documentation for bignum is confusing or wrong. > Says: > EXAMPLES > Some cool command line examples to impress the Python crowd ;) You > might want to compare them to the results under -Mbignum or > -Mbigrat: > > perl -Mbigint -le 'print sqrt(33)' > perl -Mbigint -le 'print 2*255' > perl -Mbigint -le 'print 4.5+2*255' > perl -Mbigint -le 'print 3/7 + 5/7 + 8/3' > perl -Mbigint -le 'print 123->is_odd()' > perl -Mbigint -le 'print log(2)' > perl -Mbigint -le 'print 2 ** 0.5' > perl -Mbigint=a,65 -le 'print 2 ** 0.2' > perl -Mbignum=a,65,l,GMP -le 'print 7 ** 7777' > > I run these and get:
>> perl -Mbigint -le 'print sqrt(33)'
> 5
>> perl -Mbigint -le 'print 2*255'
Show quoted text
> How are any of these 'impressive?' 2*255 = 510? Wow! > > 510+4.5=514? > > Isn't this the same as "use integer"?
[snip] The doc in "bigint" was copy&pasted from bignum/bigrat, so that might explain why it also says "this is impressive", plus why it has a few copy&past errors. However, I am pretty sure that: * 2*255 should be 2**255 (!) Not sure how that was lost? * and yes, they should all "use bigint", because that is the doc for "bigint" and it is there to show "it works, even when you throw strange things at it". * the "l,65" I probably forgot to change, I think it is now called "p" or "a" and shows that you get a fixed precision/accurary.. * getting "use bigint" to work actually *was* impressive (at least to me, because remember, before, we didn't even have "use bigint"...) because to a human "4.5 + 2" and "2 + 4.5" look the same, but to the computer these are two completely different things. * Have you actually tried "perl -le 'use integer; print log(2)'" to see if "use bigint" is really the same? Hint: One of these does the right thing and I don't think it is use integer ;) * And no, it is not anything like "use integer", because it will still work when you use 12345678901234567890/987654312 + 3... * The speed difference between things like "2 ** 255 + 0.5" and "2 ** 255" can make or break a script, if the former runs an integer calc plus a floating point add, then it will be much faster than a floating point calc + another floating point calc. Of course, these details might be lost on the reader if A: it works, either way, B: both ways are internally optimized to the same strategy, and C: the "2 ** 255" is turned into "2 * 255"... The rewriting of BigInt and BigFloat, the writing of BigRat and the conceiving of bigint/bigfloat/bigrat (and getting them into Perl!) took all a very very long time, sucked out a few years of my life, produced a lot of sweat and while it might be nowadays be something "meh" to someone (maybe someone who just uses Perl but hasen't atually tried to program such a beast like BigInt/BigFloat), I am still proud of my work, as flawed as it might be. And therefore I am also glad that others took over and fix the bugs I introduced and finish what I couldn't finish. Just sometimes I wish people would not automatically belittle the work of others when writing bug reports. All the best, Tels -- http://bloodgate.com/wiki/
Bug should be filed against bigint, not bignum. Sorry.
On Sat May 14 16:57:15 2011, LAWALSH wrote: Show quoted text
> Bug should be filed against bigint, not bignum. > Sorry.
--- When I look for the version of 'bigint', on my system:, it claims it is located in 'bignum': cpan[2]> i bigint Fetching with LWP: ftp://mirrors.kernel.org/pub/CPAN/authors/id/F/FL/FLORA/CHECKSUMS Module id = bigint CPAN_USERID FLORA (Florian Ragwitz <rafl@debian.org>) CPAN_VERSION 0.25 CPAN_FILE F/FL/FLORA/bignum-0.25.tar.gz UPLOAD_DATE 2010-09-15 MANPAGE bigint - Transparent BigInteger support for Perl INST_FILE /usr/lib/perl5/5.10.0/bigint.pm INST_VERSION 0.25 ---- So I may be confused, but it appears the bigint 'manpage' perldoc page is in the bignum distribution??
On Sat May 14 05:58:46 2011, nospam-abuse@bloodgate.com wrote: Show quoted text
> I know one shouldn't (have to) defend one self, but:
--- You are missing the point. The point is about the documentation not the implementation, so stop thinking people are attacking "all your hard work". It's obvious there is something messed up with the documentation -- and that was the point of the this report. As it is written -- it is very *unimpressive* -- which I found ironic, given how it says to use it to impress python folks. (BTW -- I know next to nothing about python, so maybe it can't do simple arithmetic, but I doubt that's the case)... So stop taking things so personally, when it's obvious some simple mistake has happened somewhere that shouldn't be too difficult to fix, once it is figured out: 1) what was really meant in the docs 2) where the docs 'belong' (why does my bigint claim it is in bignum, is that correct?) 3) and what should be in the docs to correctly impress python-fanboys. (something I'd certainly like to be armed with!)
RT-Send-CC: nospam-abuse [...] bloodgate.com
On Sat May 14 17:04:05 2011, LAWALSH wrote: Show quoted text
> > So I may be confused, but it appears the bigint 'manpage' perldoc page > is in the bignum distribution??
Yes, the "bignum", "bigint", and "bigrat" modules and documentation are all in the "bignum" distribution. You did the right thing when filing the big report against the "bignum" distribution. There will be a new release of the "bignum" distribution in a not too distant future. Hopefully, I'll get these documentation errors fixed then, although I have given higher priority to other things (specifically the fact that "use bignum" has different semantics than core Perl, resulting in different behaviour when "bignum" is present, and not giving the "transparent support" for big numbers that "bignum" claims).