Re: group identification patch

[Bill Allombert <allomber@math.u-bordeaux.fr>]

On Thu, Apr 24, 2003 at 01:27:05PM -0400, Igor Schein wrote:
> Right now I am using the following wrapper around galoisidentify() to
> ensure I never get an error:
> 
> install(galoisconj4,"GDGD1,L,D0,L,");
> idg(pol,gal)=polisirreducible(pol)||return(0);gal||gal=galoisconj4(pol);type(gal)=="t_VEC"&&return(galoisidentify(gal))
> 
> That's the best I could have done.  It illuminates the chief
> shortcomings of galoisinit() - no argument checking ( as in this:
> 
> ? galoisinit(x^2-1)
>   ***   not enough precomputed primes
> 
> ) and no usable exit status.  A crude analogy - on unix every command
> either returns zero on success or non-zero on top of any error
> messages on failure.  Here, it'd make sense for galoisinit() ( and
> many other functions as well) to return ( optionally silently, to
> reduce noise for running batches of polynomials ) zero on failure.  I
> suppose checking for irreducibility could be expensive, but returning
> zero on irreducible non-Galois input is at no extra cost.  Without
> that functionality, I have to install() galoisconj4, per Bill's
> earlier suggestion, and if I'm on a platform which doesn't support
> install(), then I either have to run an equivalent of galoisinit()
> twice or use trap(), which is horror.  So any improvement would be a
> welcome sign. 

If your platform do not suport install, just add the function to init.c
and helpmsg.c. 

The problem is again that we have no good way to handle exceptions.
trap() has a lot of problems (though I use it for this particular 
task).

Something that is probably a bad idea:

1) Add a new type t_ERROR that contain the explanation of the error.
2) Make galoisinit return a t_ERROR when a error occur.
3) Allows the user to test for t_ERROR and its content.
4) Make every PARI function raise an error() if it receive a t_ERROR.

Of course I have no idea how to implemement 4) or any variant thereof.

Cheers,
Bill.