-----BEGIN PGP SIGNED MESSAGE----- Moin Allen,
On Monday 20 December 2004 01:20, Ed Allen Smith wrote: > In message <[EMAIL PROTECTED]> (on 19 December 2004 17:00:54 > > +0100), [EMAIL PROTECTED] (Tels) wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > > > >Moin Ed, > > Allen, but don't worry about it. Oh, sorry :) Excuse my igorance, but is "Ed" some sort of prefix like "Dr."? > >On Sunday 21 November 2004 18:00, Ed Allen Smith wrote: > >> In message <[EMAIL PROTECTED]> (on 21 > >November 2004 08:34:44 -0500), [EMAIL PROTECTED] (Ed Allen > > Smith) wrote: > >> >In message <[EMAIL PROTECTED]> (on 21 > >> >November 2004 08:25:57 -0500), [EMAIL PROTECTED] > >> >([EMAIL PROTECTED]) wrote: > >> >>This distribution has been tested as part of the cpan-testers > >> >>effort to test as many new uploads to CPAN as possible. See > >> >>http://testers.cpan.org/ > >> >> > >> >>I suspect I may wind up installing this anyway: > >> On second thought, with FastCalc, the following coredumps with a > >> SIGSEGV: [schnipp] > >> With Calc: > >> > >> Can't use an undefined value as an ARRAY reference at > >> /usr/share/lib/perl5/5.8.0/Math/BigInt/Calc.pm line 980. > > > >I can reproduce this with Math::BigInt v1.73, but not with v1.74 (which I > >intent to release shortly). (It seems your script dies at the "blcm" call, > >and the reason is because you pass it BigFloats, and __lcm() could not > > handle this, nor forward them to BigFloat (because blcm() was borken in > > BigFloat since basically ever - even MBI v1.28 or so has the same > > borkened version). > > > >I noticed the non-working bgcm() and blcm() calls a few days ago, fixed it > >today, fixed something in BigInt related to __lcm(), and only then dug out > >your report and found it was also fixed :o) > > Nice when things work out that way! Yep :) > >:~/perl/math/Math-BigInt-1.73> perl -Ilib core.pl > >Can't use an undefined value as an ARRAY reference at > > lib/Math/BigInt/Calc.pm line 980. > > > >:~/perl/math/Math-BigInt-1.74> perl -Ilib core.pl > >0.029553213676353496981964883112032246577332779250091980767316223886249658 > >66492863628736572899380612750478561 > > 0.029553213676353496981964883112032246577332779250091981 > > > >Can you please retry this with v1.74 from: > > > > http://bloodgate.com/perl/packages/devel/Math-BigInt-1.74.tar.gz > > Yep, works, thanks! BTW, what exactly are the changes for 64-bit systems? > We're locally running with 64bitint (IRIX cc -n32) and long doubles, so > this is a matter of interest here... You mean in Bigint v1.74 or in FastCalc v0.07? FastCalc doesn't have any specific 64 bit code AFAIR. And I can't remember changing in 64bit for BigInt (or even testing it with that - I probably should do this..) in the last year or so.. What it basically amounts to is (warning, long winded): * FastCalc is like Calc, only that certain things are in XS to speed it up a little. It should never be slower than Calc, but it will also not be much faster (e.g. it will be linear, like factor 1.x, or 2.x - it will not change things from O(N*N) to O(N) for instance.). All it cuts down is Perl overhead. (It does not cut down overhead from BigInt itself, or overloaded math overhead on top of that.) * Basically, both Calc and FastCalc store the number in decimal, chopped into parts. * on most (32-bit) systems, each part contains 7 digits (the original BigInt v0.1 used 5 digits). On some systems (older perl, uts, unicos etc) it uses only 5 because these are known not to be able to chew on so big parts. On 64 bit systems it *could* use 8 or even 9 (depending on what fits into an integer), but reading the code I see it is now hard-coded and limited to 7, because 8 produces failures in the random-code testcases. (I always wanted to investigate how I can use 8 or 9 digits per part on 64 bit Perls. Need a reliable metric to find out when.) Hm, I should upate the "CHANGES" file. And while I am at it, swap HISTORY and CHANGES, too. * More digits per part => less parts. Since operations are O(N) etc (where N is the number of parts a certain input has), this means faster operations. * Especially on border cases and for small numbers this matters because there are many shortcuts for one-part inputs: [EMAIL PROTECTED]:~> cat bench.pl #!/usr/bin/perl -w use Math::BigInt; use Benchmark; my $c = 'Math::BigInt'; my $x = $c->new('1234567'); my $y = $c->new('1234567'); my $u = $c->new('12345678'); my $v = $c->new('12345678'); timethese (-5, { '1234567 * 1234567' => sub { $x * $y }, '12345678 * 12345678' => sub { $u * $v }, } ); [EMAIL PROTECTED]:~> perl bench.pl Benchmark: running 1234567 * 1234567, 12345678 * 12345678 for at least 5 CPU seconds... 1234567 * 1234567: 5s (5.27 usr + 0.01 sys = 5.28 CPU) 29903/s (n=157891) 12345678 * 12345678: 5s (5.24 usr + 0.01 sys = 5.25 CPU) 20957/s (n=110026) Note: Benchmark contains overhead of BigInt and overloaded math, so in reality the difference inside Calc is even bigger. * GMP stores the number internally in base-2. That means it can do certain things _much_ faster, but it might only really pay off for big/huge numbers. It is amazing that sometimes the Perl code in Calc is faster than the XS => C libgmp interface in GMP.pm :o) > >As for FastCalc failing, I intent to deprecate that package. It really > >doesn't speed things up much, but creates tons of problems due to XS. > > Oh? Interesting. It had actually speeded things up by probably a factor of > 2 or so here, albeit in comparison to 1.73 Calc. Oh. Cool. That shows that benchmarks are worthless. :) (When I wrote FastCalc, I was faszinated by how much faster loops are, f.i., in XS than in Perl - I did some quick benchmarks a few weeks ago and couldn't find anything that was substantially faster - so got the idea to "get rid of it"). The "problems" with the XS are that it introduces another maintaince package for me on top of Calc. it just duplicates a lot of code, and introduces it's own source of bugs (XS), which somehow feels all wrong to me. Anyway, I'll let FastCalc live then. Calc hasn't changed much in the last versions of BigInt - all I did was reducing the overhead in BigInt itself. The last Calc related change was in Bigint v1.70 when I simplified it's interface to BigInt (thats why a new FastCalc was also neccessary). > >If you look for a lib to replace Calc, please use 'GMP', it scales much > >better and is quite stable now. :o) > > OK, will take a look, thanks! Please tell me about the performance and whether you encounter any bugs. I am currently at releasing new versions of almost all my math modules, so that will help! Thanx for using my work and for the feedback, Tels PS: Sorry, if I buried you in technical details :) - -- Signed on Mon Dec 20 20:21:45 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "My other computer is your Windows box." -- Dr. Brad (19034) on 2004-08-13 at /. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQccsmncLPEOTuEwVAQHOLAf/S+m1jDf3RkX1z18d9mQW+WJiCie66OHe XtPu8rWOJP3T/K50Qxloa1VvNYJDNRUrlFJTUNseIIParR5jV0eHAh4XvxRpOmnw fcV/VIQR9Z54t7aqnepDhnOELdLnFWw4h9x8CRse1p+VNVZW/V07uJQ0swiAf/Vp rYYg9oXIWlK0cbMbK9/nHlsfm+QEYLwyu0jKj+9Smr+skhAvKbngFWzcLIzvA3Zg 8anmj+XagLefCdJaMHpOrJ4AQgS6IqakqO/eeuzlOPjR9B4ity4C2jnQrenc2NTa vPFUv99CISIXVi4Gi0onDI0jLzhFlNCvrnft/BaHLvYJl9GDiRsHxA== =PDpF -----END PGP SIGNATURE-----
