Karim BELABAS on Tue, 19 Jan 1999 11:15:23 +0100 (MET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: nf.sign in 2.0.12 |
> > > ? 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