Re: patch: Variable argument is always optional because it can be inferred.

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

* Sam Steingold [2017-12-14 23:40]:
> > * Bill Allombert <Ovyy.Nyybzoreg@zngu.h-obeqrnhk.se> [2017-12-14 23:28:37 +0100]:
> >
> > On Thu, Dec 14, 2017 at 04:43:06PM -0500, Sam Steingold wrote:
> >> 
> >> There are ~50 functions which accept a variable arg ("n" prototype) and
> >> everywhere except for the 3 places below it is optional.
> >> In fact, the underlying C functions accept -1, so these 3 are actually
> >> optional too.
> >
> > But they are not optional in GP, so you cannot change the prototype
> > code, this would change the GP language.
> 
> Why not change it? ;-)
> 
> > For example, 'subst(x^2+1,,y)' has never been allowed.
> 
> Why?  It seems like 'x' can be inferred.
> 
> > And it would not work:
> >
> > ? install(gsubst,"GDnG","mysubst")
> > ? mysubst(x^2+1,,y)
> > %2 = x^2+1
> > (instead of the 'expected' y^2+1).
> 
> Indeed, I tested only taylor and assumed that it would work elsewhere
> too.  In fact, it works in serprec [...]

Actually, it does not. I just reviewed the code of serprec and taylor
[ which I wrote long ago ], and tested them to check whether my
understanding matched reality [n => Dn in the prototype] and it
doesn't work there either:

1) serprec

(16:37) gp > serprec(x+O(x^10),x) \\ expected answer
%1 = 10

(16:37) gp > serprec(x+O(x^10)) \\ junk
%2 = +oo

This one could support an optional v but the semantic is not obvious:
with respect to the series main variable or with respect to the "default
variable" 'x' ?


2) taylor: will use internally v = -1 as a variable number, to which no
"name" is attached:

(16:37) gp > taylor(1)
%3 = 1 + O(t65535^16)  \\ junk

Here again it is easy to support v = -1, but with what semantic ? Wrt
the object main variable or wrt 'x' ?

E.g. if taylor(1) returns 1 + O(x^16), why shouldn't taylor(y) return 
y + O(x^16) [ instead of the "expected" y + O(y^16) ]


N.B. In both cases, the behaviour is consistent with documentation: the
code is robust enough to avoid a crash when called with an incorrect
variable number [ which the interface forbids and is impossible under GP
without modifying the GP prototypes ! ], but it doesn't support it
at this point.

> 2. Could you please fix subst? (Or would you rather have me try?)

The examples above explain the problem: I wholeheartedly agree that
evaluating a polynomial T at value 'a' can be streamlined to
poleval(T,a) but these functions can be applied to more diverse types
than polynomials.

It is easy to support "optional" variables in all cases but since there
is no obvious natural semantic (I mentioned two: wrt 'x' and wrt "main
variable") I prefer to keep everything explicit. So the variable remains
mandatory.

Also a user can easily implement

  poleval(T,a) = subst(T,variable(T), a);
  myserprec(S) = serprec(S, variable(S));
  etc.

and be done with these particular GP's quirks if he finds them
irritating and a particular semantic is obvious to him givin his
programming style and applications. (The ones above will fail in various
"natural" situations; they can be improved...)

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 21 23
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~kbelabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]
`