Karim Belabas on Mon, 08 Aug 2016 17:00:20 +0200 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: GP reference cards |
* Bill Allombert [2016-08-08 14:31]: > On Mon, Aug 08, 2016 at 01:55:34PM +0200, Karim Belabas wrote: > > I ended up adding the date of the commit obsoleting the function: > > > > % grep Obsolete: **/*(.) | sort -rk 2 > > number_fields/matbasistoalg:Obsolete: 2016-08-08 > > number_fields/matalgtobasis:Obsolete: 2016-08-08 > > They were introduced in 2008 and are quite handy. > They appear in documentation example. matalgtobasis appears, once. And the example is silly: it goes ? l = nfgaloisconj(nf); aut = l[2] \\ automorphisms in basistoalg form ? L = matalgtobasis(nf, l); AUT = L[2] \\ same in algtobasis form instead of the simpler ? aut = nfgaloisconj(nf)[2]; \\ an automorphism in basistoalg form ? AUT = algtobasis(nf, aut); \\ same in algtobasis form > Not sure why they are deprecated now. They have a purpose in library mode (because I still haven't released the 20 lines necessary to use the generic linear algebra code over 'nf' domains and we still have to user t_POLMODs for that; burried in some forgotten private branch...). In GP, it's the same reason why I now believe that applying arithmetic/transcendental functions componentwise was a bad idea. 1) Doing it systematically bloats the library code in painful ways, which are hard to test and often broken in obscure ways. 2) Users have apply() now, which behaves in understandable, generic, ways. I don't see the point of adding/keeping half-baked GP routines that do partial type conversions in very specific situations... Compare apply(a->algtobasis(K,a), M) vs matalgtobasis(K, M) OK you save a few keystrokes, but at the cost of 2 new functions that only work for this particular case instead of learning about the proper construct it only applies for these 2 functions. And they don't apply to polynomials or Lists, while apply() does. > > number_fields/factornf:Obsolete: 2016-08-08 > > I am not sure it should be deprecated. > It use a different algorithm than nffactor. Which should *always* be slower, nffactor internally chooses between the 'factornf algorithm' (Trager's trick) and 'LLL'. If you have interesting counter-examples, please file a bug report. As John said, it's confusing to have two similalry named functions doing similar things (factornf / nffactor is particularly bad since the names don't really hint at the difference) polfactormod and polfactorcantor is another example. (Here the names are better.) > > number_fields/rnfpolredabs:Obsolete: 2013-12-28 > > Why is it deprecated ? Because it serves no purpose. The point of polredabs compoared to polredbest is to have a canonical defining polynomial (at the expense of exponential time computation vs. poly-time); rnfpolredabs() doesn't provide that. Use rnfpolredbest(). > > number_fields/polred:Obsolete: 2013-03-27 > > there are quite a large number of reference to polred > in the litterature. You do remember polred's original interface, don't you ? The output is a vector of deg(T) polynomials, the first of which is always 'x-1'; the others are "relatively small" and define subfields of the original number field in no particular order. I don't want to maintain that: polredbest() is the "correct" implementation of the polred() algorithm. Input one polynomial, output another one defining the same field, with controlled coefficients. > it would be nice that typing polred would hint to polredbest instead > of failing. The whatnow mechanism already provides that effortlessly. (16:44) gp > mu(2) *** at top-level: mu(2) *** ^----- *** not a function in function call A function with that name existed in GP-1.39.15. Please update your script. New syntax: mu(n) ===> moebius(n) moebius(x): Moebius function of x. Same would occur with polred() should we remove it. > > elliptic_curves/ellpow:Obsolete: 2012-06-06 > > This GP function has been in use for a long time. Sure. Same for bezout(). I believe it's better to gradually remove things after 10 years of obsolescence, say, as in my original proposal... > > programming/global:Obsolete: 2007-10-03 > > global is used by GP2C. Then the Obsolete: tag should be removed and the documentation updated so that the user (and developers) know what the routine is good for. > > programming/listkill:Obsolete: 2007-08-10 > > Potentially used by GP2C. Same as global. If it's useful, please document it. > > It would make sense to actually remove functions that became obsolete > > long ago (before 2.5.0, say ?) > > Not before PARI 2.9.0 is released. I wasn't advocating doing it now, just as a matter of setting principles, and discussing actual functions. At some point deprecated features should become actual errors. Now, what features, and when ? Another painful one: new_galois_format. It dates from 2002, and for 14 years the documentation has been stating "The default value is 0. This value will change to 1 (set) in the next major version." (Which is technically correct : PARI/GP-3.0 hasn't been released yet :-) Cheers, K.B. -- Karim Belabas, IMB (UMR 5251) Tel: (+33) (0)5 40 00 26 17 Universite de Bordeaux Fax: (+33) (0)5 40 00 69 50 351, cours de la Liberation http://www.math.u-bordeaux.fr/~kbelabas/ F-33405 Talence (France) http://pari.math.u-bordeaux.fr/ [PARI/GP] `