rnf*

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

  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/