Karim Belabas on Sat, 18 Jan 2014 15:03:24 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
lift(s) |
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] `