Karim BELABAS on Fri, 21 Jun 2002 19:19:11 +0200 (MEST) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
rnf* |
I've just fixed two trivial bugs in the routines rnfidealnormrel / rnfidealnormabs [ used a wrong formula: results were ridiculous most of the time ! ]. Doing so I became aware of a few time bombs that have been quietly ticking away in that (mostly unused) area of the code [namely, relative computations over arbitrary number fields]: [1] a few rnf* routines build dummy nf structures to use regular nf* or ideal* routines, under the (undocumented) hypothesis that these need a restricted fixed subset of nf components. Rigid and obviously dangerous (nf interface already changed. I can construct examples where nf components are needed that are not present in the dummy structures --> SEGV) [2] the following code has become invalid in version 2.2.3 (OK in 2.2.2) nf = nfinit(base); \\ base field rnf = rnfinit(nf, ext); \\ relative extension NF = nfinit( rnf[11][1] ); \\ same viewed over Q [no member functions to \\ access rnf components...] id = ... some ideal from NF ... rnfidealrel(rnf, id); The last line is rubbish (more generally any absolute --> relative routine, when applied to NF objects which are not t_POLMODs, and any relative --> absolute routine which does not return a t_POLMOD). Reason: the NF and rnf structures are unrelated. In particular, the rnf does not know the integer basis NF.zk, which is used to express all NF objects (given by coordinates on that basis). It does know the maximal order, not the specific basis chosen. This code used to work because NF.zk was canonical, given NF.pol (HNF basis for the maximal order in terms of the power basis associated to NF.pol), and the 'rnf' included that NF.pol. Currently, this part of the documentation of 'rnfinit' (last lines) is no longer true: =============================================================================== Finally, vabs[4] is the absolute integral basis of L expressed in HNF (hence ^^^^^^ as would be output by nfinit(vabs[1])), and vabs[5] the inverse matrix of the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ integral basis, allowing to go from polmod to integral basis representation. =============================================================================== I do not see a clean solution to 2) yet. The cleanest way would be to tag NF objects so that the NF they come from is available to any routine handling the object. It would solve a lot of problems (in particular [1]) to include the absolute NF in the rnf structure, but not the compatibility problem in [2]). Karim. P.S: Reminder: the change HNF basis ---> LLL basis to represent nf objects is mandatory for algorithmic efficiency (esp. when degrees get large) P.S2: The routines using the 'rnf' structure have been introduced in version 2.1. They are very inefficient, and probably hardly ever used (so that the rnfidealnorm* bugs would go undetected for more than 5 years, for instance). It might be a better idea to redesign them than to worry about backward compatibility. -- Karim Belabas Tel: (+33) (0)1 69 15 57 48 Dép. de Mathematiques, Bat. 425 Fax: (+33) (0)1 69 15 60 19 Université Paris-Sud Email: Karim.Belabas@math.u-psud.fr F-91405 Orsay (France) http://www.math.u-psud.fr/~belabas/ -- PARI/GP Home Page: http://www.parigp-home.de/