Re: GP reference cards

Charles Greathouse
Case Western Reserve University

On Mon, Aug 8, 2016 at 11:00 AM, Karim Belabas <Karim.Belabas@math.u-bordeaux.fr> wrote:

* 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]
`