lift(s)

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

Dear all, 

  as decided during the last Atelier, I tried to make 'lift' routines more
predictable and usable. 

0) lift(x) / centerlift(x) are unaffected: although they are unusable
in complicated situations, they get the job done in simple ones; no
point in breaking compatibility there.

1) changed a little the semantic of lift(x, 'v), which lifts all
t_POLMODs in variable 'v. It used to also lift some t_INTMODs / t_PADICs
along the way (not in the lifted t_POLMOD); no longer, it now lifts
t_POLMODs in variable 'v and nothing else.

   centerlift(x, 'v) is now a deprecated alias for lift(x, 'v)

2) introduced three new functions 

- liftint(o): recursively lifts all t_INTMOD / t_PADIC components in o
  to integers (or rationals, for t_PADIC of negative valuation), and
  nothing else

- liftpol(o): recursively lifts all t_POLMOD components in o to polynomials,
  and nothing else

- liftall(o): recursively lifts all t_INTMOD/t_PADIC/t_POLMOD components in o
  so that no Mod() or t_PADIC remains in the result. Convenient for
  printing.

3) trying to lift() an object one of whose components had a
non-arithmetic type (e.g. a t_REAL or a t_STR) used to raise an
exception. Now lifts always succeed, copying verbatim non-liftable
components.


N.B. currently, elements in t_LISTs are not lifted -- but apply(lift, L)
works, or course. This is by design, and only meant to preserve
backward compatibility, but I do not feel strongly about it. It's easy
to change the code so that lists are treated as other recursive PARI
object, and lift their components as well.

These have been committed to the 'master' branch.

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