newRPL: symbolic numbers

[Claudio L.]

(12-29-2014 07:38 PM)Gilles Wrote:  All of this looks _very_ interesting...

About EVAL I would prefer to keep the EVAL of 50G and add a EVAL1 command.(that means you have to detect 'circular reference' to avoid infinite loop like X refer to Y wich refer to X ).

You're right, this is probably the way to go (is EVAL1 a good name?).

(12-29-2014 07:38 PM)Gilles Wrote:  I think that it will be interesting for the future to distinguish internaly functions and programs (a functions returns a numeric or symbolic output). For example your n. notation make sense for function but not for program.

I think there is a simple solution: if the name is specified with the trailing dot, then run EVAL to the result before using it.
If you define a function/program that always return a numeric result, then the result with the trailing dot will be the same number.
If your function/program returns a symbolic, then EVAL (or perhaps should be ->NUM instead of EVAL?) will be applied and the result will change to a number before being used.

(12-29-2014 07:38 PM)Gilles Wrote:  Perhaps you could totaly avoid something like the flag 3 of the 50G.
But I see one disavantage (?) in this : If your function is defined in symbolic

f : << -> x '3*x+5' >>

it will always return a symbolic result, unless you use the f. syntax whereas the 50G fonctionality depends of the flag 03

I'm not sure I understand. The way I envision it is this:
Once f is defined as above, typing f (no dot) will execute the program, while typing f. will execute the program and then EVAL (or ->NUM) on the result (this behavior would be the same regardless of which object is stored in f, could be a list of expressions and this would work).
The result will also depend on the argument you pass: if you pass an exact number, the result will likely be symbolic, but if you pass an approximate number, it will "eat" other numbers, and your result will be numeric, or as numeric as possible depending on the definition of the function.
If your function uses a symbolic constant, for example, it may prevent a fully numeric solution:

f: << -> X '3*X+pi' >>
where 'pi' is a constant (symbolic, no dot).
Under newRPL (proposed):
4 f --> '12+pi'
4. f --> '12.+pi'
4 f. --> 15.14... (the additional EVAL or ->NUM replaces the constant)
4. f. --> 15.14...

'f(4)' EVAL --> '12+pi'
'f(4.)' EVAL --> '12.+pi'
'f.(4)' EVAL --> 15.14...
'f.(4.)' EVAL --> 15.14...

Doing this same example on the 50g gives only slightly different results (depending on flags):
4 f --> '12+pi' (exact mode), '12.+pi' (approx. mode)
4. f --> '12.+pi' (both modes)
4 f EVAL --> '12+pi' (exact mode), 15.14.... (approx. mode)
4. f EVAL --> asks to change to approx mode, then 15.14....

'f(4)' EVAL --> '12+pi' (exact), '12.+pi' (approx mode)
'f(4.)' EVAL --> '12.+pi' (both modes, an additional EVAL will ask to switch to approx)
'f(4)' EVAL EVAL --> '12+pi' (exact), 15.14... (approx mode)
'f(4.)' EVAL EVAL --> 15.14... (approx mode), will ask to switch to approx mode if not.

Notice the double EVAL is equivalent to newRPL 'f.(x)' EVAL, as the trailing dot performs the second EVAL.


Also, this is all without using flag 3. Setting flag 3 you get a different set of results:
4 f --> 15.14...
4. f --> 15.14...
'f(4)' EVAL --> '12.+pi' (both exact and approx modes)
'f(4.)' EVAL --> '12.+pi' (both exact and approx modes)
'f(4)' EVAL EVAL --> 15.14... (both exact and approx modes)
'f(4.)' EVAL EVAL --> 15.14... (both exact and approx modes)

In this case, the CAS does not ask for permission to switch to approx mode, and returns the number 15.14... while staying in exact mode.

In newRPL, you could achieve this simply by defining:
f: << -> X '3.*X+pi' >>

That is, if you want 'f(4)' EVAL to return '12.+pi'.

If you want fully numeric results:
f: << -> X '3.*X+pi.' >>

will return 15.14.... in all the forms shown above.

(12-29-2014 07:38 PM)Gilles Wrote:  Not sure it's better or worse, but it will be different ...

I don't know either. It will sure take some time to get used to the new way. Programs will have to be crafted with the trailing dot in mind, and that means no backwards compatibility. On the other hand, if "no backwards compatibility=no awkward compatibility" I'm in favor.
I don't see a big difference in user effort to reach the desired solution (perhaps less effort?). I do see more consistency in the proposed solution, where the result depends only on what you type.

Claudio