Re: Correct use of cgetg

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

On Fri, 3 May 2002, Gerhard Niklasch wrote:

> In response to
> > Message-ID: <Pine.GSO.4.42.0205030633220.115-100000@elios>
> > Date: Fri, 3 May 2002 06:41:26 +0100 (BST)
> > From: Mark Chimley <M.Chimley@bristol.ac.uk>
> > To: pari-users@list.cr.yp.to
> > Subject: Correct use of cgetg
>
> > ... I have never created vectors before,
> > but following a read of the manual, I came up with:
> >
> > E = cgetg (6, t_VEC);
> > E [1] = gzero;
> > E [2] = gzero;
> > E [3] = A;
>
> E[1] and so forth are longs, so you should do
>
> E[1] = zero;
> E[2] = zero;
> E[3] = (long)A;
>
> etc.  (zero is the type-long incarnation of gzero).
> Cast back to GEN when you want to use a component as a GEN.

A nicer looking alternative (esp. if you handle matrices; elliptic curves
are not that bad) is simply to typecast E as a GEN*, whenever you want to
access components.

  GEN *e = (GEN*)E;
  e[1] = gzero;
  e[2] = gzero;
  e[3] = A;

  then ellpow(E,...).

It would be much nicer to be able to do something like

  struct ell E;

  E.a1 = gzero;
  E.a2 = gzero;
  E.a3 = A;
  E.a4 = gzero;
  E.a6 = B;

That's something that should have been done long ago on a large scale, but is
tedious to implement now (and also mathematically quite uninteresting, as
opposed to designing or improving algorithms...). It's been on the TODO list
for a long time.

Bill Allombert has come up with a nice idea to do that: encapsulate a
standard GEN x in a trivial TAG object describing the "conceptual" object x
(as opposed to the ordered list of components of x, which is error-prone and
terribly rigid).

That way, we can progressively update the library (by tagging current
structures ell, nf, bnf, pr, ... and adding a check for type t_TAG) AND
retain compatibility with existing pari code. New code could look like:

  GEN E = cgettag(ELL);
  pari_ell e = (pari_ell)E;

  e.a1 = gzero
  ...

So you would still have to cast, but at least the code would be readable and
we could then eventually update pari internals (e.g add components to the
structure, or remove obsolete ones).

Any "upgraded" elliptic curve routine receiving a GEN E could check

  if (typ(E) != t_TAG) E = get_ell_tag(E);

then go on with its business. [the get_ell_tag routine could do some rigorous
type checking, print a Warning if DEBUGLEVEL is set, then return a proper
tagged object]. Since the mechanism looks both useful and trivial to code, it
might appear in the very near future (in the unstable branch :-)

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas
--
PARI/GP Home Page: http://www.parigp-home.de/