Re: Online brainstorming session for GP language feature.

[Ilya Zakharevich <nospam-abuse@ilyaz.org>]

On Tue, Dec 20, 2011 at 12:05:55AM +0100, Bill Allombert wrote:
> 3) Precision:
> 
> 3.1) myprec(x): set the precision to precision(x) in the current block
> 3.2) Pi(34): return Pi with 34 digits of precision
> 3.3) Allow to handle precision in bits instead of digits.

I do not think Pi(34) is an improvement.  To explain why, I need to
introduce another "requirement".  And Pi(34) would contradict this
requirement.  [Why not have PI(34) instead?]

What is IMO very important is to have a frontend which (in its most
flexible settings) accepts inputs like

   2Pi(x+y)(x+1)
   2Pi(x+y)<super 3>(x+1)
   3 v<subscript 4><super 5>

Such front end would require two new operators in PARI (denoted below
by multiletter codes (*) [*] - but one may choose arbitrary silly
characters since they will not be produced other ways than by the
frontend).  E.g., the inputs above would be translated to
   2 * Pi (*) (x+y)**3 * (x+1)
   2 * v [*] 3 ** 5
Here [*] is the most tightly bound "macro" [*] which produces v3 if this
name is known, otherwise v[3].  (*) produces Pi(x+y) if Pi is a
function taking an argument (in this case its binding is the most
tight), otherwise it produces * (with natural priority).

    [*] "macro" is something which operates on unexpanded v, not on
        the value of v.

    Note: the priority of (*) is not known during the "skipping" part
	  of the PARI parsing.  But I suspect this will never affect
	  the result of skipping.

Anyway, if Pi takes 0 arguments (as today), then
  2Pi(x+y)(x+1) = 2*Pi*(x+y)*(x+1)
(as expected).  However, if Pi takes one argument, this would become
  2Pi(x+y)(x+1) = 2*Pi(x+y)*(x+1)
which is not what one expects from experience with math formulae.

Having Pi 0-argument, and PI 1-argument would solve this.

Yours,
Ilya

P.S.  BTW: having another operator (!*) would be handy too (but it may
      need more syntaxic conflict analysis than (*)).  Its semantic is
      the same as for (*), but its binding in the "apply" form is
      between multiplication and power; it is right associative.

      The frontend would produce it instead of (*) for input like
         WORD NONPARENTHESIS
      So
           sin sin x^3 y
      will be translated by the frontend to
	   sin (!*) sin (!*) x^3 * y
      which would be equivalent to
           sin( sin (x^3) ) * y