Re: ispolygonal

[Charles Greathouse <charles.greathouse@case.edu>]

> 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]