Math::BigInt silently drops lib argument if not available

p5pRT commented 18 years ago

Migrated from rt.perl.org#40242 (status was 'resolved')

Searchable as RT40242$

p5pRT commented 18 years ago

From @andk

What should

use Math::BigInt lib => 'Notexists';

do?

Currently it silently loads Math::BigInt::{Calc\,FastCalc} and pretends to work.

perl -le ' use Math::BigInt lib => "Notexists"; print Math::BigInt->config->{lib}; ' Math::BigInt::Calc

I think this is a serious flaw. I think it should die() to give the user a chance to fix a typo or to actually install the library he is intending to use.

I append 'perl -V' output to keep perlbug happy\, but this behaviour seems to be there since long before 5.8.0

-- andreas

Summary of my perl5 (revision 5 version 9 subversion 4) configuration: Platform: osname=linux\, osvers=2.6.16-2-k7\, archname=i686-linux-64int uname='linux k75 2.6.16-2-k7 #2 mon may 22 23:23:54 utc 2006 i686 gnulinux ' config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/pUBNkHZ/perl-5.8.0@28760 -Dinstallusrbinperl=n -Uversiononly -Doptimize=-g -des -Duse64bitint -Dusedevel' hint=recommended\, useposix=true\, d_sigaction=define useithreads=undef\, usemultiplicity=undef useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef use64bitint=define\, use64bitall=undef\, uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\, optimize='-g'\, cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion=''\, gccversion='4.0.4 20060507 (prerelease) (Debian 4.0.3-3)'\, 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=4\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.3.6.so\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='2.3.6' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E' cccdlflags='-fpic'\, lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl): Compile-time options: DEBUGGING PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Locally applied patches: patchaperlup: --branch='perl' --upto='28760' --start='17639' Built under linux Compiled at Aug 26 2006 05:26:33 @INC: /home/src/perl/repoperls/installed-perls/perl/pUBNkHZ/perl-5.8.0@28760/lib/5.9.4/i686-linux-64int /home/src/perl/repoperls/installed-perls/perl/pUBNkHZ/perl-5.8.0@28760/lib/5.9.4 /home/src/perl/repoperls/installed-perls/perl/pUBNkHZ/perl-5.8.0@28760/lib/site_perl/5.9.4/i686-linux-64int /home/src/perl/repoperls/installed-perls/perl/pUBNkHZ/perl-5.8.0@28760/lib/site_perl/5.9.4 .

p5pRT commented 18 years ago

From guest@guest.guest.xxxxxxxx

On Sun Aug 27 02:40:37 2006\, andreas.koenig.gmwojprw@franz.ak.mind.de wrote:

What should

use Math::BigInt lib => 'Notexists';

do?

Currently it silently loads Math::BigInt::{Calc\,FastCalc} and pretends to work.

It doesn't pretend\, it works be definition. The fallback library is 100% compatible. (FastCalc in itself is just optional\, the real fallback is Calc in pure perl)

You generally don't care if you have a Pentium 133Mhz or a AMD 2Ghz in your computer\, they both "work". :D

perl  \-le '
use Math&#8203;::BigInt lib => "Notexists";
print Math&#8203;::BigInt\->config\->\{lib\};
'
Math&#8203;::BigInt&#8203;::Calc
I think this is a serious flaw. I think it should die() to give the user a chance to fix a typo or to actually install the library he is intending to use.

In my mind this is not a serious flaw\, just a design choice. However\, in quite a lot of cases I noticed that you really want to make sure library "foo" was loaded\, be it for speed\, or for testing etc.

After thinking a bit\, I think the following could be added:

use Math::BigInt lib => 'GMP'; # use GMP if this fails use Calc use Math::BigInt only => 'GMP'; # use GMP if this fails\, die use Math::BigInt lib => 'Pari\, GMP'; # load GMP or Pari\, fallback Calc use Math::BigInt only => 'Pari\, GMP';# load GMP or Pari\, die otherwise

The following could produce a warnign:

use Math::BigInt only => 'GMP\, Calc';# same as lib => "GMP"

In addition\, the problem mainly arised due to speed differences\, not because the libraries do different things (they are 100% compatible).

While making FastCalc/Calc faster isn't much possible\, it should be done anyway.

A few operations could be done in XS in FastCalc\, and both Calc/Fastcalc could use more digits on 64 bit systems. But the core algorihms for mul/div scale poorly and take a lot of time in Perl due to the high number of ops. GMP simple blows the Perl code out of the water when you multiply two hundred-digit numbers\, not even talking about 1000 digits.

Best wishes\,

Tels

p5pRT commented 18 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 18 years ago

From @andk

On Sun\, 27 Aug 2006 04:02:13 -0700\, "Guest via RT" \perlbug\-followup@perl\.org said:

> On Sun Aug 27 02:40:37 2006\, andreas.koenig.gmwojprw@franz.ak.mind.de wrote:

What should

use Math::BigInt lib => 'Notexists';

do?

Currently it silently loads Math::BigInt::{Calc\,FastCalc} and pretends to work.

> It doesn't pretend\, it works be definition. The fallback library is 100% > compatible. (FastCalc in itself is just optional\, the real fallback is > Calc in pure perl)

> You generally don't care if you have a Pentium 133Mhz or a AMD 2Ghz in > your computer\, they both "work". :D

I do care. If a vendor sells me a Pentium 133Mhz and pretends to sell me an AMD 2Ghz\, it's a felony.

perl -le ' use Math::BigInt lib => "Notexists"; print Math::BigInt->config->{lib}; ' Math::BigInt::Calc

I think this is a serious flaw. I think it should die() to give the user a chance to fix a typo or to actually install the library he is intending to use.

> In my mind this is not a serious flaw\, just a design choice. However\, in > quite a lot of cases I noticed that you really want to make sure library > "foo" was loaded\, be it for speed\, or for testing etc.

In other words\, in quite a lot of cases it is a serious flaw.

> After thinking a bit\, I think the following could be added:

> use Math::BigInt lib => 'GMP'; # use GMP if this fails use Calc > use Math::BigInt only => 'GMP'; # use GMP if this fails\, die > use Math::BigInt lib => 'Pari\, GMP'; # load GMP or Pari\, fallback Calc > use Math::BigInt only => 'Pari\, GMP';# load GMP or Pari\, die otherwise

I'm curious if others agree with you\, I don't. I COULD agree with something like this:

> use Math::BigInt lib => 'GMP'\, fallback => 1; # use GMP if this fails use Calc > use Math::BigInt lib => 'GMP'; # use GMP if this fails\, die > use Math::BigInt lib => 'Pari\, GMP'\, fallback => 1; # load GMP or Pari\, fallback Calc > use Math::BigInt lib => 'Pari\, GMP'; # load GMP or Pari\, die otherwise

And I could probably agree with many other solutions\, but current behaviour should go away.

> The following could produce a warnign:

> use Math::BigInt only => 'GMP\, Calc';# same as lib => "GMP"

> In addition\, the problem mainly arised due to speed differences\, not > because the libraries do different things (they are 100% compatible).

That's correct\, but speed matters.

> While making FastCalc/Calc faster isn't much possible\, it should be done > anyway.

This is off topic at the moment. I'm not complaining about slow FastCalc/Calc. I want that a user doesn't encounter a surprise when he asks for GMP.

-- andreas

p5pRT commented 18 years ago

From easmith@beatrice.rutgers.edu

In message \87u03ywfi7\.fsf@k75\.linux\.bogus (on 27 August 2006 14:05:20 +0200)\, andreas.koenig.gmwojprw@franz.ak.mind.de (Andreas J. Koenig) wrote:

After thinking a bit\, I think the following could be added:

use Math::BigInt lib => 'GMP'; # use GMP if this fails use Calc use Math::BigInt only => 'GMP'; # use GMP if this fails\, die use Math::BigInt lib => 'Pari\, GMP'; # load GMP or Pari\, fallback Calc use Math::BigInt only => 'Pari\, GMP';# load GMP or Pari\, die otherwise

I'm curious if others agree with you\, I don't. I COULD agree with something like this:

use Math::BigInt lib => 'GMP'\, fallback => 1; # use GMP if this # fails use Calc use Math::BigInt lib => 'GMP'; # use GMP if this # fails\, die use Math::BigInt lib => 'Pari\, GMP'\, fallback => 1; # load GMP or # Pari\, fallback # Calc use Math::BigInt lib => 'Pari\, GMP'; # load GMP or # Pari\, die otherwise

That would break existing installations\, which would be a Bad Thing.

And I could probably agree with many other solutions\, but current behaviour should go away.

How about:

use Math::BigInt lib => 'GMP'; # use GMP if this fails use Calc # _and warn_ use Math::BigInt only => 'GMP'; # use GMP if this fails\, die use Math::BigInt lib => 'Pari\, GMP'; # load GMP or Pari\, fallback # Calc _and warn_

use Math::BigInt only => 'Pari\, GMP';# load GMP or Pari\, die # otherwise

The difference being the warning - that it was unable to load GMP (or Pari or whatever) and is falling back to Calc. And if you really wanted to make sure it was using GMP\, Pari\, or whatever\, you could force that with "only". (Or\, on the other hand\, if you wanted to avoid the warning\, you could add "Calc" to the end of the libraries listed for "lib".)

-Allen

-- Allen Smith http://cesario.rutgers.edu/easmith/ There is only one sound argument for democracy\, and that is the argument that it is a crime for any man to hold himself out as better than other men\, and\, above all\, a most heinous offense for him to prove it. - H. L. Mencken

p5pRT commented 18 years ago

From nospam-abuse@bloodgate.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Moin\,

On Sunday 27 August 2006 15:04\, you wrote:

In message \87u03ywfi7\.fsf@k75\.linux\.bogus (on 27 August 2006 14:05:20 [snip]

I'm curious if others agree with you\, I don't. I COULD agree with

something like this: [snip] That would break existing installations\, which would be a Bad Thing.

Exactly. So no go.

And I could probably agree with many other solutions\, but current behaviour should go away.

How about:

use Math::BigInt lib => 'GMP'; # use GMP if this fails use Calc # _and warn_ use Math::BigInt only => 'GMP'; # use GMP if this fails\, die use Math::BigInt lib => 'Pari\, GMP'; # load GMP or Pari\, fallback # Calc _and warn_

use Math::BigInt only => 'Pari\, GMP';# load GMP or Pari\, die # otherwise

The difference being the warning - that it was unable to load GMP (or Pari or whatever) and is falling back to Calc.

The warning should not be generated by default\, IMHO. Then it starts to get hairy for "GMP\, Pari\, Foo\, Calc". Should it warn if it loades Pari? Should it warn 3 times if it loades Calc? Etc. Ugh.

And if you really wanted to make sure it was using GMP\, Pari\, or whatever\, you could force that with "only". (Or\, on the other hand\, if you wanted to avoid the warning\, you could add "Calc" to the end of the libraries listed for "lib".)

Or you could just do TheRightThing[tm] if you _really_ care about it and use defensive programming like I wrote in the other email:

use Math::BigInt lib => 'Foo'; my $lib = lc(Math::BigInt->config()->{lib}); print "Using $lib\n"; die ("Cant use fastcalc or calc") if $lib =~ /^(fast)?calc\z/;

The "only" would only (no pun) make that easier and shorter to write.

Best wishes\,

Tels

- - -- Signed on Sun Aug 27 21:37:34 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.

"If Duke Nukem Forever is not out in 2001\, something's very wrong." - George Broussard\, 2001 (http://tinyurl.com/6m8nh)

- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRPH083cLPEOTuEwVAQIGPgf9EhsYWg6Sh3pTWkOKNhpHMvJdf+V3K216 jva2OpnIxs8UB/qBrI+uOufLZStMKSMRqld0FQNg3nswbh3SHQBoyulCRHy+yl7G 4pVzsnJ1WoPRAhuf04Jbqm8PjiSMrEGdy19f4YmBfTXTv1aZ428PPKkedtcmXXgH Nf7KFO+VObk9KUq1dnsnme3SNGJdiQT5PrvKHa10YiYAdUrA/ABZtMUHGaWD8jij 742l0xV8iPEq2K9pI+rJ9pTXoGCCSuD8ER+TLZqH7RYMDS1DlIrJYTKqr3pr+wdp iXcuywAeTv0FjvCwhenlBDEJ8Cr9xUf81I2Jvs7gjLs3AjkEMKOHqA== =rjOs - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRPH2jHcLPEOTuEwVAQLQjQf+KFtpaXNXHgWd5k59X2C+O3Z8Z6+Lfbgx Y+9VoMoFD8WnNmlJNGUJ3JcE9hYJQ5vpejzvaPu1T76tMbAr4waXr60X3GDGBcJG MB7q2yemx4WvMckEvk1lBGE0Efwhnpo4VjNs0/O9/CME1/T8TyDI2MyboJZX9S4p w2ffZFU4PlYYTNsqYFsbcNABUBjajmGuUNMblSnaaqXdv0KgMSreX72kmUgv0sYN WFQ3n/r2UOpcoKj5yNn+bPs7KBfR410qNg7leZMOq84ACy/i8bC6lGNt01bwPrD4 /u6fMbbnBWvoszkuc0zh4KYPtiwxv23XWMySuFmPxfiKvnxgojJgIQ== =fP/t -----END PGP SIGNATURE-----

p5pRT commented 18 years ago

From nospam-abuse@bloodgate.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Moin\,

On Sunday 27 August 2006 14:05\, you wrote:

On Sun\, 27 Aug 2006 04:02:13 -0700\, "Guest via RT" \perlbug\-followup@perl\.org said: Currently it silently loads Math::BigInt::{Calc\,FastCalc} and pretends to work.

It doesn't pretend\, it works be definition. The fallback library is 100% compatible. (FastCalc in itself is just optional\, the real fallback is Calc in pure perl)

You generally don't care if you have a Pentium 133Mhz or a AMD 2Ghz in your computer\, they both "work". :D

I do care. If a vendor sells me a Pentium 133Mhz and pretends to sell me an AMD 2Ghz\, it's a felony.

I will not even answer this because its so silly.... well I will. Instead of asking "I want to buy an AMD 2Ghz"\, you are asking him "I want a processor\, possible AMD 2Ghz\, if that is not available\, give me anything you have. And let me afterwards see what I got from you please."

Thats how the code works now\, has worked\, and will very very probably continue to work in the future. See below for why.

perl -le ' use Math::BigInt lib => "Notexists"; print Math::BigInt->config->{lib}; ' Math::BigInt::Calc

I think this is a serious flaw. I think it should die() to give the user a chance to fix a typo or to actually install the library he is intending to use.

In my mind this is not a serious flaw\, just a design choice. However\, in quite a lot of cases I noticed that you really want to make sure library "foo" was loaded\, be it for speed\, or for testing etc.

In other words\, in quite a lot of cases it is a serious flaw.

Benchmarking and running tests are two specific cases. Running normal code is another one.

And I don't agree its a serious flaw. It was designed that way and I had my reasons and I am sure I also published them widely on p5p.

Plus nobody hinders you to do this:

use Math::BigInt lib => 'Foo'; my $lib = Math::BigInt->config()->{lib}; print "Using $lib\n"; die ("Need GMP") unless $lib eq 'Foo';

After thinking a bit\, I think the following could be added: use Math::BigInt lib => 'GMP'; # use GMP if this fails use Calc use Math::BigInt only => 'GMP'; # use GMP if this fails\, die use Math::BigInt lib => 'Pari\, GMP'; # load GMP or Pari\, fallback Calc use Math::BigInt only => 'Pari\, GMP';# load GMP or Pari\, die otherwise

I'm curious if others agree with you\, I don't. I COULD agree with

something like this:

use Math::BigInt lib => 'GMP'\, fallback => 1; # use GMP if this fails use Calc use Math::BigInt lib => 'GMP'; # use GMP if this fails\, die use Math::BigInt lib => 'Pari\, GMP'\, fallback => 1; # load GMP or Pari\, fallback Calc use Math::BigInt lib => 'Pari\, GMP'; # load GMP or Pari\, die otherwise

That would break already existing scripts.

And I could probably agree with many other solutions\, but current behaviour should go away.

Why? This has been designed in around oh let me check\, yes "lib" was documented and tested and made public the first time in v1.55\, which was released March 2002. So you are about 4 years to late :/

The following could produce a warnign:

use Math::BigInt only => 'GMP\, Calc';# same as lib => "GMP"

In addition\, the problem mainly arised due to speed differences\, not because the libraries do different things (they are 100% compatible).

That's correct\, but speed matters.

Unfortunately\, there are many cases where you cannot anticipate which libarary will be actually faster.

Yes\, GMP might be faster. But it might also be slower on the system the script is currently running on. Just imagine that the standard/default library one day changes (just like it changed sometime from Calc to Fastcalc) and suddenly your program that _really_ wants GMP is slower or it doesnt work even for small numbers because GMP is not there.

While making FastCalc/Calc faster isn't much possible\, it should be done anyway.

This is off topic at the moment. I'm not complaining about slow FastCalc/Calc. I want that a user doesn't encounter a surprise when he asks for GMP.

I agree that this is a noble goal\, but since its already possible\, I am not even convinced a code change is in order. Well\, the "only" keyword would be a bit shorter to write\, thus less likely to get wrong and removing clutter.

What should be done\, however\, is to improve the documentation and point out the various subtleties of loading which library and which not.

I still can't imagine that about 4 years after it was made even possible to load other libararies\, and about 1 year after I stopped working on that project now sombody "discoveres" "serious flaws". This just means my work went by largely so unnoticed that it really doesnt matter at all. Which is just sad beyond comprehension.

All the best\,

Tels

- -- Signed on Sun Aug 27 21:20:12 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.

"helft den armen vögeln" -- gegen kleinschreibung

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRPH2kHcLPEOTuEwVAQLYyAf+Pf/azvKAiO6obmymfDjXIFfUSe2f+i7J ebi1x2cFFon3uJg5woNeYLAByIalL22pDaVAPU2aYRN1rVVJXloFukX8++KL6jGw /CsEds/OQIb9jSMhX0ltSFmsPhm9coBgR5mrTt6eAL2Xg9oMRWHsDOFE3ugVTuT0 Iqkx+v4/qNUoKrIh5ogcOE8fSXA1JR85oFMr1IKTqL5qy9fpllxAeyYesElhXZdX k86c6DbszYi2PGX65gh439vZd5eOtq35p5Qtz39lGrXQ4Kz5YAwcB1Z2NmopP/ER zGO+l+VDl4X6xZEyq0qWSqkLv8mfgHyvHQ2V6xgxurNrSl92VRQOqQ== =xUiH -----END PGP SIGNATURE-----

p5pRT commented 18 years ago

From easmith@beatrice.rutgers.edu

In message \200608272146\.20777@bloodgate\.com (on 27 August 2006 21:46:20 +0200)\, nospam-abuse@bloodgate.com (Tels) wrote:

The difference being the warning - that it was unable to load GMP (or Pari or whatever) and is falling back to Calc.

The warning should not be generated by default\, IMHO. Then it starts to get hairy for "GMP\, Pari\, Foo\, Calc". Should it warn if it loades Pari? Should it warn 3 times if it loades Calc? Etc. Ugh.

See second sentence below - if a library was named as an option\, then there should not be any warning about its use. I also did not have in mind warnings for anything other than the built-in default of "Calc".

And if you really wanted to make sure it was using GMP\, Pari\, or whatever\, you could force that with "only". (Or\, on the other hand\, if you wanted to avoid the warning\, you could add "Calc" to the end of the libraries listed for "lib".)

Or you could just do TheRightThing[tm] if you _really_ care about it and use defensive programming like I wrote in the other email:
   use Math&#8203;::BigInt lib => 'Foo';
   my $lib = lc$Math&#8203;::BigInt\->config\($\->\{lib\}\);
   print "Using $lib\\n";
   die $"Cant use fastcalc or calc"$ if $lib =~ /^$fast$?calc\\z/;
The "only" would only (no pun) make that easier and shorter to write.

Point. I'd only implement the warning (above) or the "only" option if you were doing both at the same time - convenience...

-Allen

P.S. That it's taken 4 years for someone to question this does indeed indicate that it isn't that big a deal...

-- Allen Smith http://cesario.rutgers.edu/easmith/ February 1\, 2003 Space Shuttle Columbia Ad Astra Per Aspera To The Stars Through Asperity

p5pRT commented 18 years ago

From nospam-abuse@bloodgate.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Moin\,

On Sunday 27 August 2006 23:25\, you wrote:

In message \200608272146\.20777@bloodgate\.com (on 27 August 2006 21:46:20

+0200)\, nospam-abuse@bloodgate.com (Tels) wrote:

The difference being the warning - that it was unable to load GMP (or Pari or whatever) and is falling back to Calc.

The warning should not be generated by default\, IMHO. Then it starts to get hairy for "GMP\, Pari\, Foo\, Calc". Should it warn if it loades Pari? Should it warn 3 times if it loades Calc? Etc. Ugh.

See second sentence below - if a library was named as an option\, then there should not be any warning about its use.

But Andreas wanted it to warn about the "non-usage" of one library :) This contradicts the sentence from you above. *confused*

(Or I lack sleep\, please excuse me :)

What warnings should the following generate in your opinion:

lib => "GMP\, Pari\, Foo";

When:

GMP can be loaded. GMP cannot be loaded\, but Pari could. GMP & Pari could not be loaded\, but Foo could. GMP\, Pari & Foo cannot be loaded\, but FastCalc was found. None could be loaded\, so Calc was used.

I also did not have in mind warnings for anything other than the built-in default of "Calc".

Don't forget FastCalc. It's prefered over Calc and loaded automatically\, too. Do you want warns about not finding it\, too?

And if you really wanted to make sure it was using GMP\, Pari\, or whatever\, you could force that with "only". (Or\, on the other hand\, if you wanted to avoid the warning\, you could add "Calc" to the end of the libraries listed for "lib".)

Or you could just do TheRightThing[tm] if you _really_ care about it and use defensive programming like I wrote in the other email:
   use Math&#8203;::BigInt lib => 'Foo';
   my $lib = lc$Math&#8203;::BigInt\->config\($\->\{lib\}\);
   print "Using $lib\\n";
   die $"Cant use fastcalc or calc"$ if $lib =~ /^$fast$?calc\\z/;
The "only" would only (no pun) make that easier and shorter to write.
Point. I'd only implement the warning (above) or the "only" option if you were doing both at the same time - convenience...

I am not really against a warning\, but I am just confused on what it should warn\, and how to disable it.

Yes\, from my own struggles to always print outwhat lb was used for benchmarks it should have been clear to me that a "short" way to really enforce a lib would be nice\, but I alwas thought that this is only relevant for benchmarks of math libs\, or testcases anyway.

Real world usage indicates that you dont't really care whatever does the work\, as long as it gets done.

And since the only reason why I didnt actually make GMP always the first choice is that it can be slower for small numbers and the user should better decide which library he wnts to prefer/try first.

However\, in praxis people slap on a "lib => 'GMP';" as a magic silver bullet\, though\, and not much thinking about it. Hmprf.

\-Allen
P.S. That it's taken 4 years for someone to question this does indeed indicate that it isn't that big a deal...

All the best\,

Tels

- -- Signed on Sun Aug 27 23:59:28 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.

This email violates U.S. patent #6\,756\,999 \<http://tinyurl.com/2vuqm>:

[ [ Konsoles* ] [ Mozilla ] [ KMail ]]

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRPIYTHcLPEOTuEwVAQJCWQf+LeokO0y/kglIJ1j+5PutcpIKPUDExod5 yNGXkziSXlZf/WAac4ZyKjxQHxhDYBkXSjWBS1rsgehhU27A1wXIE5n7l7fmf8/G GXwh5AXENJ5+4Bz6dSxZA+9s0gN/nXa16rlaeAQVPF7OQwinSujHMVP9P0Wx0FGj +oCer3yMW9tOKtflTHbRUbiF1Z+Pp9w7ayPG3g2/Dt6uUtqd43dPtrh6szcvD75a qjCRKTY6Ym1r2HoUVsoE+vidJEVG9hXqV6xtOqveWDoJVgDzQHDhkH7KiTqQ3xVU h7CJUZtBS0bj9jZ+lHiVCW6J/7qaR+2kcKwz8PQUg3A0bNDqpwelzg== =Gzgz -----END PGP SIGNATURE-----

p5pRT commented 18 years ago

From easmith@beatrice.rutgers.edu

In message \200608280010\.20289@bloodgate\.com (on 28 August 2006 00:10:20 +0200)\, nospam-abuse@bloodgate.com (Tels) wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Moin\,

On Sunday 27 August 2006 23:25\, you wrote:

In message \200608272146\.20777@bloodgate\.com (on 27 August 2006 21:46:20

+0200)\, nospam-abuse@bloodgate.com (Tels) wrote:

The difference being the warning - that it was unable to load GMP (or Pari or whatever) and is falling back to Calc.

The warning should not be generated by default\, IMHO. Then it starts to get hairy for "GMP\, Pari\, Foo\, Calc". Should it warn if it loades Pari? Should it warn 3 times if it loades Calc? Etc. Ugh.

See second sentence below - if a library was named as an option\, then there should not be any warning about its use.

But Andreas wanted it to warn about the "non-usage" of one library :)

This contradicts the sentence from you above. *confused*

It's quite possible that I've misunderstood Andreas' concern.

(Or I lack sleep\, please excuse me :)

Understand!

What warnings should the following generate in your opinion:

lib => "GMP\, Pari\, Foo";

When:

GMP can be loaded.

No warning.

GMP cannot be loaded\, but Pari could.

No warning.

GMP & Pari could not be loaded\, but Foo could.

No warning.

GMP\, Pari & Foo cannot be loaded\, but FastCalc was found.

Warn\, I think\, since FastCalc was not listed explicitly.

None could be loaded\, so Calc was used.

Warn\, since Calc was not explicitly listed.

I also did not have in mind warnings for anything other than the built-in default of "Calc".

Don't forget FastCalc. It's prefered over Calc and loaded automatically\, too.

I hadn't remembered that; thank you.

Do you want warns about not finding it\, too?

Not if it wasn't explicitly named.

I am not really against a warning\, but I am just confused on what it should warn\, and how to disable it.

Understand.

Yes\, from my own struggles to always print outwhat lb was used for benchmarks it should have been clear to me that a "short" way to really enforce a lib would be nice\, but I alwas thought that this is only relevant for benchmarks of math libs\, or testcases anyway.

What if people are wanting to benchmark|test|see how to speed up a program that uses the math libs?

And since the only reason why I didnt actually make GMP always the first choice is that it can be slower for small numbers and the user should better decide which library he wnts to prefer/try first.

It could also slow down program loading (a concern for frequently-invoked programs)\, expand memory usage\, or whatever\, depending on the system and situation.

However\, in praxis people slap on a "lib => 'GMP';" as a magic silver bullet\, though\, and not much thinking about it. Hmprf.

Sigh...

-Allen

-- Allen Smith http://cesario.rutgers.edu/easmith/ There is only one sound argument for democracy\, and that is the argument that it is a crime for any man to hold himself out as better than other men\, and\, above all\, a most heinous offense for him to prove it. - H. L. Mencken

p5pRT commented 18 years ago

From @andk

On Sun\, 27 Aug 2006 18:25:30 -0400\, Allen Smith \easmith@beatrice\.rutgers\.edu said:

But Andreas wanted it to warn about the "non-usage" of one library :)

This contradicts the sentence from you above. *confused*

> It's quite possible that I've misunderstood Andreas' concern.

My original perlbug posting said:

What should use Math::BigInt lib => 'Notexists'; do? [...] I think it should die()

I agree that it's a bit late to discuss an interface decision that was taken and documented 2001. Time limit for appeal expired. Sorry for coming so late.

I would welcome if you could come up with a usable syntax that makes the used library predictable. If you cannot come up with a new syntax\, I suppose the following would work\, right?

use Math::BigInt::Foo; # guarantees that Foo is there use Math::BigInt lib => 'Foo'; # must use Foo now\, right?

If this is the shortest way to express that I want 'Foo' and nothing else\, so be it and then please document it.

Thanks\, -- andreas

p5pRT commented 18 years ago

From nospam-abuse@bloodgate.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Moin\,

sorry for the late reply\, real life catching up with me:

On Monday 28 August 2006 00:25\, you wrote:

In message \200608280010\.20289@bloodgate\.com (on 28 August 2006 00:10:20 [snip]

What warnings should the following generate in your opinion:

lib => "GMP\, Pari\, Foo"; When: GMP can be loaded. No warning. GMP cannot be loaded\, but Pari could. No warning. GMP & Pari could not be loaded\, but Foo could. No warning. GMP\, Pari & Foo cannot be loaded\, but FastCalc was found. Warn\, I think\, since FastCalc was not listed explicitly. None could be loaded\, so Calc was used. Warn\, since Calc was not explicitly listed.

ok\, I think I get your meaning: it should warn whenever it falls back to a library that was not explicitely mentioned\, no matter on what it falls back.

I think Andreas means essentially the same\, although he only gave the case for a single "wanted" library\, and he wants it to die.

Having the ability to warn/die is usefull\, IMHO\, and I see why you want them. Nows only the question how to implement it in a backwards compatible manner. Two ideas I thought up:

use Math::BigInt lib => 'GMP\,Pari'; # warns now on fallback use Math::BigInt only => 'GMP\,Pari'; # dies on fallback

The problem with that case is that there is no easy way to shutup the warning.

Second idea:

use Math::BigInt lib => 'GMP\,Pari'; # no warning use Math::BigInt try => 'GMP\,Pari'; # warns on fallback use Math::BigInt only => 'GMP\,Pari'; # dies on fallback

"try" could also be "prefer".

Both ideas have the slight problem that they will only work with newest BigInt versions should you use one of the new keywords. This means if you expect them to work on older systems\, you need to do:

use Math::BigInt "1.78"\, only => 'GMP'; # only works with GMP

But this can't really be avoided.

Andreas\, would this solve your isse\, too?

I am sure that it won't help the benchmark where this came up\, for two reasons:

* the machine it runs on wont have the newest BigInt * and even if it has\, it doesn't have Math::BigInt::GMP on it :-/

Plus\, one could argue that using a third-party-library (e.g. non-core) is really "cheating".

Yes\, from my own struggles to always print outwhat lb was used for benchmarks it should have been clear to me that a "short" way to really enforce a lib would be nice\, but I alwas thought that this is only relevant for benchmarks of math libs\, or testcases anyway.

What if people are wanting to benchmark|test|see how to speed up a program that uses the math libs?

Well\, when you write up benchmarks\, you must ensure extra care that they work they way you wanted them to work. So\, you really would double check. E.g. use the already working examples using "config->()->{lib}" I already gave. :)

But I agree that it could be more easy to write\, and the documentation is not optimal\, I would know about the issues because I implemented it\, while everyone else might easily miss them.

And since the only reason why I didnt actually make GMP always the first choice is that it can be slower for small numbers and the user should better decide which library he wnts to prefer/try first.

It could also slow down program loading (a concern for frequently-invoked programs)\, expand memory usage\, or whatever\, depending on the system and situation.

However\, in praxis people slap on a "lib => 'GMP';" as a magic silver bullet\, though\, and not much thinking about it. Hmprf.

Sigh...

Well\, see bullet "insufficient documentation" above :)

All the best\,

Tels

- -- Signed on Fri Sep 1 12:26:28 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.

"...no one would risk manipulating votes in an election because it's against the law and carries a heavy penalty..." -- Diebold spokesman David Bear

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRPgNVXcLPEOTuEwVAQLPuQf+LLw7PTKHVjX8zUvCqE+iFmeRob3JpsO0 025ZqzTD69Hk6p2AzGBjtf006dquuaiYmAsTOM7lZHkoueVCbzT0yZKQXiZLunVC 8q8GOG65Oxh3TvwB3/I0iDxe57t4TS8oahCN/wuHPI42e8WtNH6GZ1eryRDlqQMV fVgH8LeSpnIriFHGz5W78Csd/C2s+hnb5PzywzD3yf60/tOij8LH0anunncU7DZn jECrM3z1N6DQOTL7KjUvIKTX+xpYerpHgHPtfrZJCuUhUdwe3ut3Tgy6RXOkZdMo m7JAfZg0RNLBL9thWZg+lazLhs7+6cCBmtPTxnVZe0pOW7EVESB07w== =7J/V -----END PGP SIGNATURE-----

p5pRT commented 18 years ago

From nospam-abuse@bloodgate.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Moin\,

On Monday 28 August 2006 08:46\, you wrote:

On Sun\, 27 Aug 2006 18:25:30 -0400\, Allen Smith \easmith@beatrice\.rutgers\.edu said:

But Andreas wanted it to warn about the "non-usage" of one library :)

This contradicts the sentence from you above. *confused*

It's quite possible that I've misunderstood Andreas' concern. [snip]

I would welcome if you could come up with a usable syntax that makes the used library predictable. If you cannot come up with a new syntax\, I suppose the following would work\, right?
use Math&#8203;::BigInt&#8203;::Foo;         \# guarantees that Foo is there
use Math&#8203;::BigInt lib => 'Foo'; \# must use Foo now\, right?
If this is the shortest way to express that I want 'Foo' and nothing else\, so be it and then please document it.

This would'nt really work\, because just Math::BigInt::Foo exists\, is loadable etc doesn't mean it is a library that BigInt can use. For instance the interface is checked\, e.g. that the right function are there etc. So if you have an outdated version of Foo on your system\, it would "pass" you test\, but happily use Calc. :)

The current shortest\, and backwards compatible way to write what you want is exactly what I gave already as example:

use Math::BigInt lib => 'Foo'; # try Foo die ("need Foo") unless Math::BigInt->config()->{lib} =~ /:Foo\z/;

Side note:

Technically\, the library can even change at run time\, and other libraries like Math:BigFloat use callbacks to get notified of such changes:

Witness:

# cat b2.pl use Math::BigInt lib => 'Calc'; use Data::Dumper; print Dumper(Math::BigInt->new(123))\,"\n"; Math::BigInt->import( lib => 'GMP' ); print Dumper(Math::BigInt->new(123))\,"\n";

# perl b2.pl $VAR1 = bless( { 'value' => [ 123 ]\, 'sign' => '+' }\, 'Math::BigInt' );

$VAR1 = bless( { 'value' => bless( do{\(my $o = 9672512)}\, 'Math::BigInt::GMP' )\, 'sign' => '+' }\, 'Math::BigInt' );

The reason why this rarely occurs and shouldnt be used is that the math really only works when both numbers are of the same lib. Once you mix them\, everything goes up in flames.

The callback system is nec. to make sure things like:

perl -MMath::BigInt -e 'use Math::BigInt lib => "GMP";"

work\, e.g. where the library changes _before_ any math is done. (Think: caching of constants or math lib function pointers).

Doing math before and after a library change is risky.

Best wishes\,

Tels

- - -- Signed on Fri Sep 1 12:47:22 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.

"The Palmer proposal. What ever happened to that?"

- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRPgSUXcLPEOTuEwVAQLnCwf9GwbvDDWvzKkj33KRfvjCUfhw7Q4KUO57 9z/7fKj3Pu47NRzHX+ht8HK8n/1U8cE/1PrDKssbG8NEKrjoHxX4mXn9EnfZqvQi ZfzCfRWluDuTscieeOxZgBumSjGWNgSBSXefiPt74bIl30Sks02nMnxuYA3BD2tp AfIpivucFgiartNpOnqt1qIhvquc3KCfCNw4ifS0S91rlnHhTp4/6W6xKy0U5thu 2Ahr1lZBKA8j6DFN2GJw4KC+MFufDhG35NuFyHGjCjtlXj2BUOevEAZY7KL86GYR HlD8SJmxIrJk+Ka+Qx3EQwGQ8NCO0JI3V+ZkJFhA0aJmHbCqcLQ3SQ== =dxYN - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRPgeqncLPEOTuEwVAQKG8wf+IxfEfgkEjreEo3sq6lAda0RWRpiFLUdW PpBpzf+NXrbChxIGxU7aY0HOaNby4wq42cr3MbN4av3NDcEI9U9pFlxVktKX/f0l VLP1391wfgiMwZqxezY96NAi81mzR/PRxGHr065Qo/t7faIk6WBtwj9WhktDihaC 3WQZTpgf3TxWOZ7zu0/ztdoZKuKG2rCJVMy5PnHBdv1JIHwtpXrZpjSTZnBzodBR Pt1F0OdRwUrELja7ufK/HB2RIpOFtMYCb/FV87XtbJHXtE/lgIuXkTgrnkpOS03+ UFVOnVzIeICpCYU/wQYzOXWxCElWF+SdN118Reaja1T+Ti0gR9o6BQ== =Awbv -----END PGP SIGNATURE-----

p5pRT commented 18 years ago

From @andk

On Fri\, 1 Sep 2006 12:37:09 +0200\, Tels \nospam\-abuse@bloodgate\.com said:

lib => "GMP\, Pari\, Foo"; When: GMP can be loaded. No warning. GMP cannot be loaded\, but Pari could. No warning. GMP & Pari could not be loaded\, but Foo could. No warning. GMP\, Pari & Foo cannot be loaded\, but FastCalc was found. Warn\, I think\, since FastCalc was not listed explicitly. None could be loaded\, so Calc was used. Warn\, since Calc was not explicitly listed.

> ok\, I think I get your meaning: it should warn whenever it falls back to a > library that was not explicitely mentioned\, no matter on what it falls > back.

> I think Andreas means essentially the same\, although he only gave the case > for a single "wanted" library\, and he wants it to die.

I have been convinced that breaking compatibility is not acceptable here. From this point of view I find the above solution good.

> Having the ability to warn/die is usefull\, IMHO\, and I see why you want > them. Nows only the question how to implement it in a backwards compatible > manner. Two ideas I thought up:

> use Math::BigInt lib => 'GMP\,Pari'; # warns now on fallback > use Math::BigInt only => 'GMP\,Pari'; # dies on fallback

> The problem with that case is that there is no easy way to shutup the > warning.

> Second idea:

> use Math::BigInt lib => 'GMP\,Pari'; # no warning > use Math::BigInt try => 'GMP\,Pari'; # warns on fallback > use Math::BigInt only => 'GMP\,Pari'; # dies on fallback

> "try" could also be "prefer".

> Both ideas have the slight problem that they will only work with newest > BigInt versions should you use one of the new keywords. This means if you > expect them to work on older systems\, you need to do:

> use Math::BigInt "1.78"\, only => 'GMP'; # only works with GMP

> But this can't really be avoided.

> Andreas\, would this solve your isse\, too?

Yes\, it would\, because it ensures that the program dies when either Math::BigInt is too old or GMP is not available.

> I am sure that it won't help the benchmark where this came up\, for two > reasons:

> * the machine it runs on wont have the newest BigInt

These guys keep their machines very well uptodate. Of course\, this means that we probably have to wait till 5.8.9\, but maybe one can talk them into simply installing GMP without changing the script. I'll make up my mind later.

> * and even if it has\, it doesn't have Math::BigInt::GMP on it :-/

This can be ensured as soon as the program *demands* GMP.

> Plus\, one could argue that using a third-party-library (e.g. non-core) is > really "cheating".

This can be argued easily given that other languages also use gmp.

> [...]

Thanks for looking into it\, Tels.

-- andreas

p5pRT commented 18 years ago

From nospam-abuse@bloodgate.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Moin\,

On Friday 01 September 2006 22:34\, you wrote:

On Fri\, 1 Sep 2006 12:37:09 +0200\, Tels \nospam\-abuse@bloodgate\.com said:

[snip] I think Andreas means essentially the same\, although he only gave the case for a single "wanted" library\, and he wants it to die.

I have been convinced that breaking compatibility is not acceptable here. From this point of view I find the above solution good.

Cool. Now I have to get of my lazy ass and actually implement it. Ugh...:)

Having the ability to warn/die is usefull\, IMHO\, and I see why you want them. Nows only the question how to implement it in a backwards compatible manner. Two ideas I thought up:
use Math&#8203;::BigInt lib => 'GMP\,Pari';    \# warns now on fallback
use Math&#8203;::BigInt only => 'GMP\,Pari';    \# dies on fallback
The problem with that case is that there is no easy way to shutup the warning.

Second idea:
use Math&#8203;::BigInt lib => 'GMP\,Pari';    \# no warning
use Math&#8203;::BigInt try => 'GMP\,Pari';    \# warns on fallback
use Math&#8203;::BigInt only => 'GMP\,Pari';    \# dies on fallback
"try" could also be "prefer".

Both ideas have the slight problem that they will only work with newest BigInt versions should you use one of the new keywords. This means if you expect them to work on older systems\, you need to do:
use Math&#8203;::BigInt "1\.78"\, only => 'GMP';    \# only works with GMP
But this can't really be avoided.

Andreas\, would this solve your isse\, too?
Yes\, it would\, because it ensures that the program dies when either Math::BigInt is too old or GMP is not available.

Good. I myself prefer the idea with "try" and "only" added as keywords. Any other opinions?

I am sure that it won't help the benchmark where this came up\, for two reasons:

* the machine it runs on wont have the newest BigInt

These guys keep their machines very well uptodate. Of course\, this means that we probably have to wait till 5.8.9\, but maybe one can talk them into simply installing GMP without changing the script. I'll make up my mind later.

* and even if it has\, it doesn't have Math::BigInt::GMP on it :-/ This can be ensured as soon as the program *demands* GMP.

Well\, or they just list the benchmark then as "failed" :-P

Plus\, one could argue that using a third-party-library (e.g. non-core) is really "cheating". This can be argued easily given that other languages also use gmp.

Looking at this\, they seem to mention specially that they allow gmp as math library.

The challange here is to tell them that apart from installing newest BigInt and the libgmp\, that they also need Math::BigInt::GMP :)

(I do consider all these benchmarks flawed anyway\, suffering from the problem of calculating things in a way that you wouldn't really use in a real-world program anyway. Recursive ackerman? etc :)

all the best\,

tels

- -- Signed on Sat Sep 2 06:17:17 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.

"...pornographic images stay in the brain forever." -- Mary Anne Layden; "That's a feature\, not a bug." -- God

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRPkG0ncLPEOTuEwVAQL7uAf+IoWjxVNcOPU/8AP91q0DQrLwai58tZqs 1eJ9TICsTwG6e8VKjOcFZWrC7QoLwPzTXV5W1aFFatthC1SwkcLo1vhd78T+MdxT U3UfSQnob/Ri41LNKvJL7aEu5HOg8VYJ9nqo/oWL9NNjd92yYqDrQ8PZ4TpMELD4 2gorJ0Ek5rgxTzDKOIpHhnc1BrvufKwdLt/DPIJcr/8LTnylO4iqMeHDUbgSoBC3 10Lpg31Qs+S/Lk2urCOGdOujhhtrl/4Vq6d5KBtEl3lecPqGTN8471mBkkpHCiyY yyCi/cBc6Tm6Y4QO8S07ebF1I13xSlKmDgFoMcjBHBVMhi8cGZGomw== =CRWq -----END PGP SIGNATURE-----

p5pRT commented 16 years ago

p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'

Perl / perl5