Ilya Zakharevich on Tue, 20 Dec 2011 03:00:41 +0100

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 Re: Online brainstorming session for GP language feature.

```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.  (*) 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

```