Karim Belabas on Sat, 07 Jun 2008 00:50:56 +0200 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: Number fields for polynomials with rational coefficients |
* 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] `