Re: nf.sign in 2.0.12

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

> > > ? nf.sig
> > >   ***   incorrect type in .sign: nf.sign
> > > 
> > > (I also got a segfault when execution the same later in a long session.)
> > 
> > It's not exactly a bug: since the defining polynomial had to be changed, the
> > output is not a real "nf" since it also gives the transformation. But I guess
> > it doesn't hurt to support that format also. 
> > 
> > [Beware that most PARI functions which expect a number field won't
> > recognize that format: since we changed user's data behind his back, it looks
> > better to have user acknowledge the fact and do nf = nf[1] himself, if he
> > doesn't care about the transform.]
> 
> Can you convert this technobabble into documentation?  Or is it
> mentioned in 2.0.13 already?  I have 2.0.12, and cannot find any entry
> on possible different output from nfinit().
> 
> Oh, I see.  It says "computes a 9-component vector", it does not say
> "return a 9-component vector".  I think this chunk of doc should start
> with description of the return value.
> 
> Or better, nfinit() should be fixed to always return nf - unless flag=3.

Since this behaviour is shared by the other *init functions, it is documented
only once, at the beginning of the section (III.6). [Since at least version
2.0.10 (I think)]. From ??nf, or ??bnf [, or (2.0.14) ??"Functions related to
general number fields"]: 
============================================================================
   P  is  the defining polynomial for the number field,  which must be in
Z[X], irreducible  and,   preferably,   monic.    In fact,  if you supply a
non-monic polynomial  at  this  point,   GP  will  issue  a warning,  then
transform your polynomial so that it becomes monic. Instead of the normal
result, say res, you then get a vector [res,Mod(a,Q)], where Mod(a,Q) =
Mod(X,P) gives the change of variables.
============================================================================

In ??nfinit you just have "preferably monic", as a reminder.

I don't consider nfinit to be broken. The output is tricky to use otherwise
in case you were not expecting your polynomial to be changed: all
elements/ideal/... will be given with respect to a different basis than the
one you supplied. Mostly, you'll only be able to check the invariants
(discriminant, etc), and for that you're probably better off using a
specialized function: polsturm, nfdisc, nfbasis, etc.

If you expect to use non-monic polynomials and insist on forgetting about the
change of basis, use nfinit(..., 2)


What do others think ?

  Karim.
--
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://pari.home.ml.org