Re: Number fields for polynomials with rational coefficients

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

* Jeroen Demeyer [2008-06-06 22:58]:
> I was wondering why nfinit() allows non-monic polynomials in Z[x], but  
> why not polynomials in Q[x]?  Apparently you already check for the  
> content of the argument to nfinit(), because nfinit(3*x^2+3) ==  
> nfinit(x^2+1).

The only reason why nfinit() allows non-monic polynomials or the
flag > 1 variants is that polredabs + nfinit would compute the integer
basis twice (and LLL-reduce it twice, but the second LLL should be cheap),
which is a waste.

A generic implementation providing exactly that same functionality
in a more flexible way is:

  B = nfbasis(pol);            \\ or nfbasis(pol, 1), etc...
  C = polredabs([pol, B], 1);  \\ or polred, etc...
  pol = C[1];
  B = lift( subst(B, variable(pol), C[2]) );

  nfinit([pol, B])

Since it's a bit cumbersome, it would be nicer if polred / polredabs
provided a flag corresponding to the first 4 lines, i.e provide 
- a better defining polynomial
- a change of variable (from original to better pol)
- AND the integer basis (in terms of the better pol)

Then nfinit could be properly restricted to monic integral polynomials
and we could depend on specialized functions (polred) to find a good defining
polynomial, instead of overloading with weird flags an essentially
unrelated function (nfinit), leading to unnecessarily complicated output
types: either nf or [nf, change of variable]; 'nf' in all cases would
be nicer (and relieve a few other functions from the burden of
checking these fringe [nf, change] occurrences to discard the 'change').

It's trivial to implement (cf the 4 lines above), but requires adding
yet another flag to functions (polred/polredabs) which already have
inconsistent sets of flags under GP, kept only for backward
compatibility [ internally, in libpari, we use different different
(simpler/cleaner/more efficient) data structures and functions :-( ]


Using symbolic flags (see ??ploth) would be fine, less error-prone and
easier to extend, but of course would not prevent existing scripts using
hardcoded values to break. The one reason why we have not introduced
symbolic flags all over the place.

Leaving everything the way it is now just seemed the lesser evil...

But I'll gladly welcome any bright idea for painless transition schemes
to get rid of those hardcoded numeric "binary flags" [ simple zero/non-zero
flags are not a problem and could be kept ].

Something better than "Welcome to GP-3.0, silly numeric flags are no longer
allowed, please update your scripts to use the current clean symbolic
equivalents".



> I actually came across this problem with polredabs(),  
> where it makes even more sense to allow polynomials in Q[x].

Oh, right. This one was an oversight. A one-line fix in svn
(did I mention that libpari does things in a much more flexible way ?)

Thanks for spotting this, and sorry for the rambling answer !

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-bordeaux.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]
`