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[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