Re: GP reference cards

[John Cremona <john.cremona@gmail.com>]

It is confusing(*) to users to have both factornf and nffactor
existing, doing similar things (or the same thing using a different
algorithm).  Fine to have a choice of algorithm, but surely that
should be determined by having an additional paramater on a single
function?

John

(*) Proof: I have been confised by this.  More than once, since my
memory is not perfect.

On 8 August 2016 at 13:30, Bill Allombert
<Bill.Allombert@math.u-bordeaux.fr> wrote:
> On Mon, Aug 08, 2016 at 01:55:34PM +0200, Karim Belabas wrote:
>> * Karim Belabas [2016-08-08 13:24]:
>> > * Bill Allombert [2016-08-08 12:52]:
>> > > On Mon, Aug 08, 2016 at 12:36:26PM +0200, Karim Belabas wrote:
>> > > > * Jeroen Demeyer [2016-08-08 09:34]:
>> > > > > On 2016-08-06 20:40, Karim Belabas wrote:
>> > > > > > N.B. All non-deprecated GP functions
>> > > > >
>> > > > > Speaking of deprecation, is there a machine-readable way of determining
>> > > > > whether a given GP function is deprecated? I think we talked about this at
>> > > > > the PARI atelier. It would be useful to add some flag to pari.desc for
>> > > > > deprecated functions.
>> > > >
>> > > > Yes, the current situation is a little awkward. The following script
>> > > > produces the list of obsolete defaults and functions with master
>> > > > (it doesn't in 2.8.0: misses 2 or 3 functions).
>> > >
>> > > Maybe we could simply add a RFC822 field Obsolete: yes
>> >
>> > I agree. That's what I meant by "awkward" :-)
>>
>> 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.
> Not sure why they are deprecated now.
>
>> number_fields/factornf:Obsolete: 2016-08-08
>
> I am not sure it should be deprecated.
> It use a different algorithm than nffactor.
>
>> linear_algebra/qfnorm:Obsolete: 2016-08-08
>> linear_algebra/qfbil:Obsolete: 2016-08-08
>> number_fields/bnrconductorofchar:Obsolete: 2015-11-11
>> polynomials/bezoutres:Obsolete: 2015-01-13
>> conversions/sizedigit:Obsolete: 2015-01-13
>> default/strictmatch:Obsolete: 2014-10-11
>> default/compatible:Obsolete: 2014-10-11
>> elliptic_curves/ellbil:Obsolete: 2014-05-21
>
>> number_fields/rnfpolredabs:Obsolete: 2013-12-28
>
> Why is it deprecated ?
>
>> number_fields/rnfpolred:Obsolete: 2013-12-28
>> polynomials/poltchebi:Obsolete: 2013-04-03
>> number_theoretical/bezout:Obsolete: 2013-04-03
>> number_fields/polred:Obsolete: 2013-03-27
>
> there are quite a large number of reference to polred
> in the litterature. it would be nice that typing polred would
> hint to polredbest instead of failing.
>
>> elliptic_curves/ellpow:Obsolete: 2012-06-06
>
> This GP function has been in use for a long time.
>
>> programming/trap:Obsolete: 2012-01-17
>> number_fields/polredord:Obsolete: 2008-07-20
>> programming/global:Obsolete: 2007-10-03
>
> global is used by GP2C.
>
>> programming/listkill:Obsolete: 2007-08-10
>
> Potentially used by GP2C.
>
>> programming/listcreate:Obsolete: 2007-08-10
>
>> graphic/plotpointtype:Obsolete: 2007-05-11
>> graphic/plotpointsize:Obsolete: 2007-05-11
>> graphic/plotlinetype:Obsolete: 2007-05-11
>> transcendental/bernvec:Obsolete: 2007-03-30
>>
>> N.B. pari-2.7.0 was released on 2014-03-24
>>      pari-2.5.0 was released on 2011-06-22
>>      pari-2.3.0 was released on 2006-05-19
>>
>> 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.
>
> Cheers,
> Bill.
>