Re: new GP functions varhigher / varlower

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

* Andreas Enge [2014-11-28 11:51]:
> 
> On Wed, Nov 26, 2014 at 07:11:46PM +0100, Karim Belabas wrote:
> >   varhigher(name, {v}): return a variable 'name' whose priority is higher than
> >   the priority of v (of all existing variables if v is omitted).
> > 
> > 1) [WONTFIX] variables created via varhigher / varlower can not be accessed by
> > typing their name (or the quote operator 'foo). This is by design: the same
> > (display) string can be associated to many variables. A given symbol can be
> > associated to only one of them.
> 
> I understand that this applies to the programmer's responsability, but is
> their a potential use for this confusing behaviour?

Yes: writing and distributing portable GP code. Without it

- Either you introduce an indirection level, call your variables v1, v2,
  ... and require users to always pass on variable names, which is
  cumbersome. (This is the main reason we now define 'x' and 'y': have a
  sensible default for variables in modular polynomials.)

- Or you fix your own names which are 99% guaranteed to be no longer
  available with the proper priority if your package is not the first
  one loaded into gp.

etc. 

A better theoretical solution (orthogonal to PARI philosophy) would be
to define formally and explicitly a polynomial ring before any
polynomial could be created, as in Magma or Sage. Then a polynomial
contains a pointer to its parent domain and arbitrary collections
of variables could have a *local* meaning: any specific collection 
of object would belong to a specific polynomial ring with a fixed
variable ordering, independently of the rest of GP.

Having different variables printed in the same way emulates part
of this without the hassle of requiring explicit prior definitions.

E.g. if you want a tower of fields 
  K = Q[x]/(T) \subset L = K[y]/(U) \subset M = L[z]/(V)
you start with

  y = varhigher("y", x);
  z = varhigher("z", y);

and you're done. If the next package author wants his polynomials in
((Q[z])[y])[x], fine, he can have them.

  y = varlower("y", x);
  z = varlower("z", y);

and both packages can coexist. Of course both package must use their
own x, y, z and never rely on 'x, 'y, 'z (which will in general refer to
different variables)

> Local variables?

No, local variables ( actually, variables lexically scoped via my() )
are "inlined": their name is no longer a concern.

> But as I understand it, these symbols are global anyway?

Yes. That's the main problem.

> How about checking unicity of the string?

As explained above, this would defeat the purpose of those functions.

> Or dropping the first argument?

This is consistent, useful (would create fewer variables) and easy to
implement: return *any* variable whose priority satisfy the
requirements, without caring about how it is displayed.

I can add this without problem.

Unfortunately, since the current interpreter creates far too many
polynomial variables [ e.g. one for each user function ], you will end
up with really polynomials if you ever need to display them, e.g. to
debug your program. 
> This would only work in assignments, however: t=varhigher() could
> create a variable with string "t".

This doesn't work: varhigher() is not implemented in the parser and
doesn't know about assignments; also you can certainly create variables
without assigning them to any symbol, or associate them to lexically
scoped symbols (which don't really have names), etc.


Thanks for the feedback !

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-bordeaux1.fr/~kbelabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
`