Re: GP: ffinit() bug

[Michael Somos <somos@grail.cba.csuohio.edu>]

Thank you for the additional information, but this is a bit difficult
to accept. I tried other values. For example :

? ffinit(6,2)
%2 = Mod(1, 6)*x^2 + Mod(1, 6)*x + Mod(2, 6)

and even though there is no field 'F_6' it returned a result. The result
may be nonsense, but that may be up to the user to decide. What is hard
to accept is the infinite loop. However, if that is the desireable way
to go, a clear warning about this seems to be in order. There is no way
to always protect the user from himself, but we can try. Shalom, Michael 

On Tue, 30 Apr 2002, Bill Allombert wrote:

> On Mon, Apr 29, 2002 at 10:48:55PM -0400, Michael Somos wrote:
> > Pari Developers,
> >      Using the up-to-the-minute CVS I find :
> >               (readline v2.2 enabled, extended help not available)
> > ? ffinit(4,2)
> > ^C  ***   user interrupt after 23,010 ms.
> > 
> > which appears to be an infinite loop. Shalom, Michael
> 
> 4 is not a prime number, so the behaviour of ffinit is undefined in this case.
> Maybe the doc is misleading, it is written F_p, and F_4 make sense, but
> it is universally agreed that p is a prime else we wrote F_q, I think.
> 
> Testing the primality of p is not a option, since the new ffinit
> is much faster than ispseudoprime or even BSW_psp() for large p.
> 

> 
> Fixing the oo-loop is a little difficult.  The algorithm looks for a odd prime
> number l so that 4 is not a square modulo l.  Of course it will never find it,
> but that give no information on the fact that 4 is not a prime, unless we use
> Lagarias-Odlyzko bound but this is not really practical.
> 
> Cheers,
> 
> Bill.
> 
> PS: there is a CVS branch for the stable version named 'release-2-1-patches'.
> You can also check it out if you are interested.
>