Charles Greathouse on Wed, 09 May 2012 14:34:58 +0200 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: ispolygonal |
> This is a bit far-fetched and potentially confusing, I temporarily changed > it to e_MISC. > > Presumably we need a general error type for "violated inequality" ? I've wished for an error type for bad input (other than type). Making it "violated inequality" gives the user more information but limits its scope. Either would be fine. Object-oriented languages would make a "bad input" error type which encloses both violated inequality and type errors, but I don't think we want/need that kind of structure. > What do people think about the function name ? Obviously, > ispolygonalinteger() would be clearer but quite a bit more verbose than > our usual functions. I like the current name for brevity. If for some reason we added code to detect, say, figurate polynomials I would prefer to subsume the functionality into the current ispolygonal() than to add another function ispolygonalpoly(). Charles Greathouse Analyst/Programmer Case Western Reserve University On Wed, May 9, 2012 at 8:20 AM, Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr> wrote: > * Bill Allombert [2012-05-08 23:34]: >> I am experimenting with ispolygonal: >> >> ? ispolygonal(36,2) >> *** at top-level: ispolygonal(36,2) >> *** ^----------------- >> *** ispolygonal: incorrect type in ispolygonal (t_INT). >> >> This is confusing since 2 is a t_INT. > > The rationale was to avoid the e_MISC error type [ which is essentially > impossible to trap cleanly ], and consider that the expected input > "type" was 'a t_INT in Z_{> 2}'. > > This is a bit far-fetched and potentially confusing, I temporarily changed > it to e_MISC. > > Presumably we need a general error type for "violated inequality" ? > > pari_err(e_INEQ, "ispolygonal", "s > 2", s); > > ==> > > incorrect value in %s (need %s). Was: %s > > > Similar checks occur quite often, > > (14:13) gp > vector(-1) > *** at top-level: vector(-1) > *** ^---------- > *** vector: incorrect type in vector [negative dimension] (t_INT). > > pari_err(e_INEQ, "vector", "n >= 0", n); > > > (14:16) gp > primes(-1) > *** at top-level: primes(-1) > *** ^---------- > *** primes: incorrect type in primes [negative dimension] (t_INT). > > pari_err(e_INEQ, "primes", "n >= 0", n); > > (14:18) gp > sigma(0) > *** at top-level: sigma(0) > *** ^-------- > *** sigma: zero argument in an arithmetic function. > > pari_err(e_INEQ, "sigma", "x != 0", x); > > etc. > > >> >> ? [ispolygonal(36,3,&N),N] >> %7 = [1,9223372036854775816] >> >> N is wrong obviously >> >> ? [ispolygonal(33496046025275818831719453356591156886^2,3,&N),N] >> %19 = [1,47370562574818466718159911997304784776] >> >> N is wrong, it should be 47370562574818466708936539960450008968 > > Both of these had the same origin, and were specific to s = 3 [ which > I had special-cased anyway, but not enough, thereby later treating s - 4 > as an ulong ]. Fixed in master. > > What do people think about the function name ? Obviously, > ispolygonalinteger() would be clearer but quite a bit more verbose than > our usual functions. > > Cheers, > > K.B. > -- > Karim Belabas, IMB (UMR 5251) Tel: (+33) (0)5 40 00 26 17 > Universite Bordeaux 1 Fax: (+33) (0)5 40 00 69 50 > 351, cours de la Liberation http://www.math.u-bordeaux1.fr/~belabas/ > F-33405 Talence (France) http://pari.math.u-bordeaux1.fr/ [PARI/GP]