Threaded Mode | Linear Mode

Claudio L. · 12-22-2014, 11:01 PM

Here's an idea to eliminate the "approximate" vs "exact" mode.
What if symbolic numbers are allowed to remain symbolic?

On the 50g, typing '2' (by being quoted, the user intended this as a symbolic expression with the number 2 inside) is automatically converted to the number 2 (ZINT or real depending on flags).
But what if the number was kept symbolic?
This would (in theory) eliminate the need for two separate modes of operation.
When the user wants a quantity to be symbolic, just adding quotes will keep it symbolic.
Within programs, instead of changing flags all the time, or issuing an error, you'd simply quote the quantities and all results would come up symbolic, or leave the numbers unquoted to get a real (approximate) result.
To convert from symbolic to number, the usual ->NUM would work, and we'd need the opposite to turn an existing number into a symbolic (perhaps ->SYMB?).

The idea would be something like this:
{ 1 2 3 4 5 } '2' / would return { '1/2' '2/2' '3/2' '4/2' '5/2' }
{ 45 '45' } SIN would return { 0.707... 'SIN(45)' }
2 INV --> 0.5
'2' INV --> '1/2'

In other words, quoted numbers would work more like symbolic constants do now.

BTW, reals within symbolics are already treated as first class citizens, so quoted reals will work just fine:
'1.5/4' DUP * EVAL returns 0.14.... even in exact mode on the 50g because of the real number in the expression. This same code returns the symbolic '9/64' in newRPL.

Am I missing something? Could this achieve the goal of eliminating the mode switching nightmare? Any problems that could arise from doing this?

John Galt · 12-23-2014, 01:13 AM

I think it's brilliant. Using quotes around a number to indicate a symbolic is elegant and intuitive, and I can't think of any disadvantage to that entry method. Proposing it in the manner you have makes me wonder why HP didn't already implement it that way.

Going the other way (turning what is now a real or imaginary number back to a symbolic) seems like unscrambling an egg though. The only solution I can imagine would require keeping a practically limitless memory of every step the user did to get to that point. Unless you're talking about a simple one-level "undo" though, which we already have.

Granted I haven't thought about it very much, but it seems a concept worthwhile exploring.

Nigel (UK) · 12-23-2014, 12:06 PM

(12-22-2014 11:01 PM)Claudio L. Wrote: BTW, reals within symbolics are already treated as first class citizens, so quoted reals will work just fine:
'1.5/4' DUP * EVAL returns 0.14.... even in exact mode on the 50g because of the real number in the expression. This same code returns the symbolic '9/64' in newRPL.

Am I missing something? Could this achieve the goal of eliminating the mode switching nightmare? Any problems that could arise from doing this?

Suppose I have an expression 'r=d/2'. If I store '7' or '7.0' (both quoted) in d, I'd expect to get 7/2 for r when this expression is evaluated. If I store 7.0, I'd expect to get 3.5 and not 7/2. I'm not sure what I'd expect if 7 (without the quotes) was stored in d.

My point is that real numbers or numbers in standard form are generally not intended to be exact. Unless they are deliberately quoted they should stay approximate, even if they appear inside a quoted expression. If this is what you intend your idea seems excellent.

Nigel (UK)

Claudio L. · 12-23-2014, 03:10 PM

(12-23-2014 12:06 PM)Nigel (UK) Wrote: Suppose I have an expression 'r=d/2'. If I store '7' or '7.0' (both quoted) in d, I'd expect to get 7/2 for r when this expression is evaluated. If I store 7.0, I'd expect to get 3.5 and not 7/2. I'm not sure what I'd expect if 7 (without the quotes) was stored in d.

That's a good point. Being that 'r=d/2' is a symbolic expression, once the number is replaced inside the expression, there's no way to tell if it came from a number or a symbolic number, so it would always return 'r=7/2' (doesn't matter if it's 7 or 7.0 in this case).

(12-23-2014 12:06 PM)Nigel (UK) Wrote: My point is that real numbers or numbers in standard form are generally not intended to be exact. Unless they are deliberately quoted they should stay approximate, even if they appear inside a quoted expression. If this is what you intend your idea seems excellent.

You raised a very good point. Replacement inside an expression would always convert a number into symbolic. This differs from the current status-quo but then, if you are manipulating symbolic expressions, why shouldn't it be symbolic?
You are expecting 'r=3.5' and not 'r=7/2' , but is this only a consequence of how the 50g works (that makes you expect that), or a standard in other mathematical software?.
Does anyone know if any other calculators or math software behaves that way?

Claudio L. · 12-23-2014, 03:34 PM

(12-23-2014 01:13 AM)John Galt Wrote: Going the other way (turning what is now a real or imaginary number back to a symbolic) seems like unscrambling an egg though. The only solution I can imagine would require keeping a practically limitless memory of every step the user did to get to that point. Unless you're talking about a simple one-level "undo" though, which we already have.

What I had in mind was this:

3.14 --> '3.14'

Just adding the quotes! Wasn't thinking of undoing operations to get the original expression that led to the number (that would be cool, but like you said we'd need a more powerful device, perhaps a phone/tablet to keep the history).
Within the limitation we have, at most something like QPI could be implemented.

Claudio L. · 12-23-2014, 05:22 PM

(12-23-2014 12:06 PM)Nigel (UK) Wrote: Unless they are deliberately quoted they should stay approximate, even if they appear inside a quoted expression.

Thinking about this a little deeper, perhaps it could be implemented the way you describe.
Inside symbolics, numbers would have to be flagged as either exact or approximated, effectively moving from a global flag to a flag on each number.

Following the idea that an approximated number "turns" an exact number into approximated this would be:

'1' '1/2' + --> '3/2'
'1' 0.5 + --> '1.5' (here 1.5 would be an approx. symbolic number)
'3/2*X' 3 * --> '4.5*X' (here 4.5 is approx)
'3/2*X' '3' * --> '9/2*X'

The other approach would be the opposite: exact numbers turn approximated numbers into exact:
1 '1/2' + --> '3/2'
'1' 0.5 + --> '3/2'
'3/2*X' 3 * --> '9/2*X'
'3*X' 1.5 * --> '9/2*X'

I can't see any problem with either approach, perhaps a flag "prefer exact" or "prefer approx." could select between these two approaches, but we are back to a system-wide flag, not too different from "exact mode" in the 50g, except if you use only quoted numbers, or only unquoted numbers, the flag won't affect your results (only the mix would present problems).

The main difference of doing this vs. the 50g would be that exact and approximated terms can coexist within the same expression:

'3.5*X+7/2*Y' (where we'd have to indicate somehow when we type the expression that the 3.5 is approximated, otherwise it's exact even though is not an integer)

Adding 'X' to the above expression, would be:
'3.5*X+7/2*Y' 'X' + --> '4.5*X+7/2*Y' (using prefer approx.)
'3.5*X+7/2*Y' 'X' + --> '9/2*X+7/2*Y' (using prefer exact)

Notice the second term remains unaltered. The above example on the 50g triggers the "Approximate mode on?" question (after pressing EVAL). If accepted, it kills all fractions in the expression, if not accepted it errors and returns the original expression '3.5*X+7/2*Y+X'.

One more problem with this:
Typing a whole expression from the keyboard, we need to indicate somehow when a number is exact or not. Outside a symbolic we add quotes, but what to do when we are typing inside a symbolic?

'3.5*X' typed would make 3.5 an exact number, so:
'3.5*X' DUP * would return a fraction (49/4), as we would be multiplying two exact numbers.

We'd also need a way to visually distinguish exact vs approx. numbers on screen (bold font?).

Nigel (UK) · 12-23-2014, 05:57 PM

In Mathematica (from memory) and in the AUTO mode (i.e., neither EXACT nor APPROX) on TI calculators such as the TI-89, the status of a number as exact or approximate is indicated by the presence or absence of a decimal point. So 40320 is an exact number, while 40320. is approximate. Sin[4] in Mathematica simply returns Sin[4] (i.e., no evalulation), whereas Sin[4.] returns a real number. One approximate number in a calculation poisons the rest of the calculation, so that 3/2 +0.5 would be 2. rather than 2 , and substituting d=7. into 'r=d/2' would give 3.5 for r.

I have always found this to work well. When using my TI calculators (yes! I do use them and I'm not ashamed!!) I cannot remember ever needing the EXACT or APPROXIMATE modes.

I think that the quoting idea could work in the same way as the decimal point approach so long as one unquoted number poisons the entire expression it appears in. I think this is reasonable: if one number is inexact, anything calculated from that number must also be inexact. Maybe the decimal point approach would be easier for the user to enter, though? It is quicker to type 2*(3+4) than '2'*('3'+'4'). However, the elegance of the quoting idea is very appealing! I'm really not sure what is best.

Nigel (UK)

Claudio L. · 12-23-2014, 09:01 PM

(12-23-2014 05:57 PM)Nigel (UK) Wrote: It is quicker to type 2*(3+4) than '2'*('3'+'4').

Typing is the only problem I see with using quotes. In your example, it's much more comfortable to type the dot.
You'd have to press the quote, type the number, then cursor right to get out of the quote.
Makes writing expressions a pain.

Or, accept that every number you type inside quotes will become exact, dot or no dot.
Would that be a nuisance?

A last resort could be to use a trailing dot as the approx. indicator inside symbolics:
2 is a number --> approx.
'2' is symbolic --> exact
'2.5' is symbolic, dot is there but is not trailing --> exact
'2.5.' is an approx. number

brouhaha · 12-23-2014, 09:27 PM

(12-23-2014 05:57 PM)Nigel (UK) Wrote: It is quicker to type 2*(3+4) than '2'*('3'+'4').

Yes, but wouldn't one just type that as '2*(3+4)' ?

Nigel (UK) · 12-23-2014, 09:49 PM

(12-23-2014 09:01 PM)Claudio L. Wrote:
(12-23-2014 05:57 PM)Nigel (UK) Wrote: It is quicker to type 2*(3+4) than '2'*('3'+'4').

Typing is the only problem I see with using quotes. In your example, it's much more comfortable to type the dot.
You'd have to press the quote, type the number, then cursor right to get out of the quote.
Makes writing expressions a pain.

Or, accept that every number you type inside quotes will become exact, dot or no dot.
Would that be a nuisance?

A last resort could be to use a trailing dot as the approx. indicator inside symbolics:
2 is a number --> approx.
'2' is symbolic --> exact
'2.5' is symbolic, dot is there but is not trailing --> exact
'2.5.' is an approx. number

The trailing dot is a reasonable idea. However, is it necessary? I'm not sure why anyone would want a number like 2.5 to be treated as an exact number. Perhaps this is because I'm a physics teacher - I insist that all calculated results are given to an appropriate number of significant figures, usually no more than three. Anyone who writes 5/2 ohms for the resistance of a resistor would lose a mark, because they are claiming to know the resistance to an infinite number of significant figures and that can never happen.

So I would suggest:

2 or 2. is a number --> approx.
'2' is symbolic --> exact
'2.5' is symbolic --> approx because of the dot
'2.5.' is symbolic ... --> exact! Exact numbers with decimals might be needed sometimes, but for me at least they would be a rare occurrence and so they should be the harder of the two to type.

I'm not entirely happy with this either. I shall continue to think!

Nigel (UK)

Claudio L. · 12-24-2014, 03:15 AM

(12-23-2014 09:49 PM)Nigel (UK) Wrote: The trailing dot is a reasonable idea. However, is it necessary? I'm not sure why anyone would want a number like 2.5 to be treated as an exact number.
Perhaps this is because I'm a physics teacher - I insist that all calculated results are given to an appropriate number of significant figures, usually no more than three. Anyone who writes 5/2 ohms for the resistance of a resistor would lose a mark, because they are claiming to know the resistance to an infinite number of significant figures and that can never happen.

Sometimes in engineering you end up with expressions that are for the most part theoretical, then patched with some obscure real coefficients. It's not that I believe the coefficient is exact (it was likely picked arbitrarily by a committee of researchers that had too much caffeine), but I don't like that coefficient to "eat" all other exact coefficients which do have a meaning.

For example, a simple beam deflection formula at the center: d=5/384*w*L^4/EI, where 5/384 are exact numbers from symbolic integration. But then the engineers mess it up with let's say a factor of 1.5 to account for long term material behavior, making it:
d=1.5*5/384*w*L^4/EI

In cases like this, it's better if 1.5 behaves like an exact value (eventually converted to 3/2), so it's easier to preserve the 5/384 fraction that engineers quickly recognize as a "simple beam formula adjusted with some factor", rather than some obscure factor that you don't know where it comes from.

The other case is also true: sometimes you want that factor to eat all other numbers and give you a single real coefficient. For example if you are doing tables for different cases of the beam deflection above and you just want the final coefficient.
The tables can be expressed as d= m * (w*L^4/EI), where your m=k*5/384, and k varies according to different factors (it may even be integer or 1).
In that case, you want the k value to be treated as approx. and "eat" the fraction, to produce the desired expression format.

The issue is sometimes more visual than related to the significance of the number itself.

(12-23-2014 09:49 PM)Nigel (UK) Wrote: So I would suggest:

2 or 2. is a number --> approx.
'2' is symbolic --> exact
'2.5' is symbolic --> approx because of the dot
'2.5.' is symbolic ... --> exact! Exact numbers with decimals might be needed sometimes, but for me at least they would be a rare occurrence and so they should be the harder of the two to type.

I'm not entirely happy with this either. I shall continue to think!

Nigel (UK)

Seems reasonable, but how would you type a symbolic integer that is approximated?
'2.' --> exact
'2' --> exact

Gilles · (This post was last modified: 12-24-2014 04:30 PM by Gilles.)

It seems to me there is a confusion between 'symbolic' and 'exact' here.
Note that the way the 50G works is very different depending of FLAG 03 set or not

Claudio L. Wrote:Following the idea that an approximated number "turns" an exact number into approximated this would be:

'1' '1/2' + --> '3/2'
'1' 0.5 + --> '1.5' (here 1.5 would be an approx. symbolic number)
'3/2*X' 3 * --> '4.5*X' (here 4.5 is approx)
'3/2*X' '3' * --> '9/2*X'

In my opinion, the HP50G 'philosophy' is that there is very few automatic evaluation with symbolic calculation so,i prefer :

Code:

'1' '1/2' + --> '1+1/2' then EVAL (or SIMPLIFY) -> '3/2'  or NUM->  1.5

'1' 0.5 +   --> '1+0.5' then EVAL -> '1.5'  ( approximate 'contagion' but algebraic object)  NUM-> 1.5  (real object)

'3/2*X' 3 * --> '3/2*X*3'  then EVAL '9/2*X' (If X does not exist else  returns  the evaluated expression...)

'1.5' '3.14' + COS --> 'COS(1.5+3.14)'

I like the idea to have a full control of what happens...

Claudio L. Wrote:The other approach would be the opposite: exact numbers turn approximated numbers into exact:
1 '1/2' + --> '3/2'
'1' 0.5 + --> '3/2'
'3/2*X' 3 * --> '9/2*X'
'3*X' 1.5 * --> '9/2*X'

I hate this way Sad

Why don't keep something like the approx ( ~ )and exact ( = ) on the 50G with some improvments ?

in '=' mode ( CAS mode ?) :
- All is symbolic, you have to do ->NUM to get a numeric (no symbolic) result.
- functions returns symbolic results

enter 12 will return '12' (algebraic object)
enter 12. will return '12.' (algebraic)
enter '12.' will return '12.' (algebraic)

ex:

Code:

1 1 2 / +  -> '1+1/2' EVAL -> '3/2'

1.1. 2. / + 'x' * -> '(1.+1./2.)*x'  EVAL (or SIMPLIFY)  -> '1.5*x' (if x undefined)

'1.' '1.' '2.' / + -> '1.+1./2.'  EVAL (or SIMPLIFY)  -> '1.5' 

'SIN(1)' EVAL -> 'SIN(1)'

'SIN(1.) EVAL -> 'SIN(1.)'  

1 '1.5' + -> '1+1.5'   EVAL (or SIMPLIFY)  -> '2.5' 

PI 4  /SIN -> 'SIN(PI/4)'  EVAL -> 'V2/2' (the 50G auto eval in these cases)

`Function` is the same as 'Function'  EVAL  (Auto evaluation of algebraic objects)

in '~' mode (numeric mode):
- All is numeric, you have to quote 'xxx' for algebraic
- functions returns numeric results (and an error if there are undefined values)

enter 12 is the same as 12.
but you can force '12' to get the algebraic object '12' with an integer inside.
or '12.' for an algebraic object '12.' with a real only inside

ex

Code:

12  -> 12.

1 1 2 / + -> 1.5

'1' '1' '2' / +  -> '1+1/2'   EVAL (or SIMPLIFY)  -> '3/2'  ->NUM -> 1.5

'1.' '1' '2' / +  -> '1.+1/2'   EVAL (or SIMPLIFY)  -> '1.5'

1.1. 2. / + -> 1.5

SIN(1)  -> 0.841...

PI 4  /SIN  -> 0.707...

'1' 1.5 + -> 2.5

The difference between = and ~ will be essentialy in the way to input the data in the calc to reduce keystrokes and numeric or algebraic output for functions (that means that there must be a difference between a function (manipulation of algebraic objects) and programs (manipulation of all kinds of objects ...).

= more oriented 'math' (CAS)
~ more oriented 'physics' and numeric calculations

The other major difference will be that with "= mode"
'1' 1. + -> '1+1.'

and in "~ mode"
'1' 1. + -> 2.

In others words

Code:

'blabla'  is an algebraic object (no automatic evaluation)

`blabla` is an algebraic object auto evaluated 

'13.33' is an algebraic object with one real object inside

'1+2' is an algebraic object with an expression)inside '+(1,2)'

13.33 is a real object

13 is an integer object (but I think new RPL dont use integer)

13. is a real object

...

= and ~ just change few (but important) things for more easy use and less keystrokes. You can easily toggle from = to ~ with Shift & ENTER.

~ mode works in the same way of the old 48 serie
== mode is near the 'exact' mode of the 49/50G series but different in some way (and more logical for me but probably i miss some points)
.
Note that in this configuration you _must_ use symbolic to work with 'infinite" integer. (but i've not understand how new RPL will work for this ...).

Just my 2 cents !

I'm quite sure that what I write here is not fully coherent and more 'theoric' thoughts is needed for this.

The keys:
- functions returns 'sym' or 'num' ?
- exact vs approx
- is there an 'infinite integer' type or not ?
- When 'evaluate' ?
- SIMPLIFY vs EVAL

Claudio L. · 12-24-2014, 07:51 PM

(12-24-2014 11:12 AM)Gilles Wrote: It seems to me there is a confusion between 'symbolic' and 'exact' here.

Yes! We are several people thinking out loud, it is normal for our thoughts to be incoherent sometimes.

Here's what I got in clear from all of the posts above:
* Using quotes to distinguish exact vs. approximate numbers seems cool at first, but is insufficient (as it makes all numbers exact within a symbolic).
* Using the trailing dot to distinguish exact vs approximate numbers is one good option and agrees with other systems (feels more familiar).

(12-24-2014 11:12 AM)Gilles Wrote: In my opinion, the HP50G 'philosophy' is that there is very few automatic evaluation with symbolic calculation so,i prefer :

Code:

'1' '1/2' + --> '1+1/2' then EVAL (or SIMPLIFY) -> '3/2' or NUM-> 1.5 '1' 0.5 + --> '1+0.5' then EVAL -> '1.5' ( approximate 'contagion' but algebraic object) NUM-> 1.5 (real object) '3/2*X' 3 * --> '3/2*X*3' then EVAL '9/2*X' (If X does not exist else returns the evaluated expression...) '1.5' '3.14' + COS --> 'COS(1.5+3.14)'

Yes! We were taking shortcuts in the explanations, but certainly you'd have to EVAL the expression before a number eats another one. We never meant that this was going to happen automatically in one shot.

(12-24-2014 11:12 AM)Gilles Wrote: I like the idea to have a full control of what happens...

And I agree. The idea of eliminating the global flag exact vs. approx. is to give you more control, not less. You may want evaluation of parts of an expression to a number, but symbolic treatment on others. This is not possible right now on the 50g, but would be if you can control which values are approximated and which are exact.

Let's say you have an expression:
'3.5.*X+7/2*Y+SIN(X)' (where the 3.5. is an approximated number, see what I did with the trailing dot? doesn't look so bad)

Let's say you want to replace X with a value, to obtain a linear function in Y alone.

The 50g will want approx mode (just because you have a real in there), which will turn the whole expression into a number, and issue an error if Y is not defined when you EVAL.

The whole idea is to prevent that and make it behave more the way you'd expect:
If you have a value for X and not Y, just replace the value for X. Then EVAL will operate on all approx. numbers within the expression, and leave the exact ones alone.

In the expression above, if you put an approximate number in X, (and after various EVAL's) you'll end with an expression:

'n.nnnn.+7/2*Y' (where n.nnnn. is a real approx. number)

If you put an exact number in X (let's say 4.5, but exact - no trailing dot), you'll end up with (again, after a few EVALs):

'15.75.+7/2*Y+SIN(4.5)'

In this case, the 3.5. (approx.) ate the 4.5, but the other term with the SIN() function remains symbolic because 4.5 is exact.
I hope this clarifies the intent.

(12-24-2014 11:12 AM)Gilles Wrote: - is there an 'infinite integer' type or not ?

I'm taking this question out of context, I know, but this is the main reason that all this cannot work the same on newRPL as it was on the 50g. newRPL has infinite 'reals', so we are not limited to integers within symbolics. As a matter of fact, large integer numbers will be represented with reals (there's no choice).
The 50g defined any real number within a symbolic to be an 'approximated' number. Worse, it infects the whole expression, making the expression "approximated", and in the end, it forces the whole system to switch into "approximated" mode.
newRPL *has* to allow reals within symbolics, so we must find another way to distinguish exact vs. approx. numbers. I thought the quotes would work at first, but in an expression you can't distinguish them. Now I'm back to the trailing dot but this time including reals with a trailing dot also.
At the same time, I don't like that one approximated number in an expression forces a system-wide mode change (that will affect all subsequent expression evaluations, whether they have a real or not). I think you should be able to control the numeric/symbolic output from within the expression, and not affect other expressions.

So the light at the end of the tunnel seems to be:
* Forget about quoted numbers.
* Use the trailing dot to signal approximated numbers. No trailing dot means exact. This works both outside and inside a symbolic expression.

2 --> exact
2. --> approx
1.5 --> exact
1.5. --> approx
1.3e1000 --> exact
1.3e1000. --> approx

The opposite (using the dot for exact numbers) could be used too, but most integer numbers in an expression would need to be typed with the dot (exact), and that makes it slower to type.

Claudio L. · 12-29-2014, 03:19 PM

(12-24-2014 07:51 PM)Claudio L. Wrote: * Forget about quoted numbers.

Actually, I'd like to take that back.
Reading back the whole thread made me realize this still needs quoted numbers:

Quote:The idea would be something like this:
{ 1 2 3 4 5 } '2' / would return { '1/2' '2/2' '3/2' '4/2' '5/2' }
{ 45 '45' } SIN would return { 0.707... 'SIN(45)' }
2 INV --> 0.5
'2' INV --> '1/2'

So quoted numbers will exist, alongside the trailing dot:

{ 45 45. '45' '45.' } SIN
will return {0.707... 0.707... 'SIN(45)' 'SIN(45.)' }
and after EVAL, {0.707... 0.707... 'SIN(45)' 0.707... }

Also, I think the trailing dot concept could also be extended to variable identifiers and constants.
For example, typing:
π will leave the symbolic constant π on the stack.
But typing π. (with the dot) should leave 3.1415.... on the stack.

Same thing for variables. If the variable name is followed by a dot, it is interpreted as an approximated expression, and upon evaluation, it's numeric value will be calculated and returned, as if ->NUM was executed.
For example:
2 'X' STO
'X^2' 'Y' STO

Now, typing
Y will leave 'X^2' on the stack.
Y. will leave 4 on the stack.

'Y+1' EVAL will leave 'X^2+1' and another EVAL will produce the number 5.
'Y.+1' EVAL will produce '4+1' and another EVAL the number 5.

Note: The need for multiple EVAL's is because as of now newRPL CAS doesn't do recursive substitutions (the 50g would show the number 5 on the first EVAL). Perhaps a command EVALALL will be added, or perhaps EVAL will behave like the 50g, and a new command like EVAL1 will do a non-recursive single-step as shown above, this is still in the works and subject to change.

Any thoughts about these "extensions"?

Gilles · 12-29-2014, 07:38 PM

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 ).

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.

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

Not sure it's better or worse, but it will be different and if we only want to work with numeric results (and dont use the f. syntax) we could do

f : << 3. * 5. + >>
or
f : << -> x '3*X+5' ->NUM >>
or
f : << -> x '3.*X+5.' ->NUM (or EVAL ) >>

Han · 12-29-2014, 09:33 PM

Why not simply use ~ as a unary operator to denote an approximate number?Otherwise, everything is exact.

Claudio L. · 12-29-2014, 10:21 PM

(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

Gilles · (This post was last modified: 12-30-2014 10:08 AM by Gilles.)

Quote: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...

OK.

In my opinion, the '.' is ->NUM and not EVAL.

By the way, the unary operator ~ suggested by Han seems the same as ->NUM. I like this ~ notation.
And perhaps f~ would be more explicit that f. And in this case, both f~ and f ~ will be correct

'pi' ~ will return 3.14159...

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

for the 2 last, with the suggestion of Han

'f~(4)' EVAL --> 15.14...
'f~(4.)' EVAL --> 15.14...
or
'f(4)' ~

I would like this but the disadvantage is that the ~ is not directly on the keyboard with only a keypress on the contrary of .

Quote:(...) 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 agree. Anyway you already have loosed the backward compatibility with better behavior of DOSUBS , DOLIST, ADD, + ...

Quote: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.

OK.

Another thing, I like that uppercase and lowercase are not the same thing in commands and functions in RPL.
But i would be pleased if all the native commands and functions in newRLP will use lowercases instead of uppercases : start next , for next , cos, sin ... (or Start For Next Cos, Sin) are more readable and less agressive than START NEXT or FOR NEXT COS SIN

Claudio L. · 12-30-2014, 02:19 PM

It seems Han's suggestion is merely changing the symbol from the dot to ~. Other than that, it appears to have the exact same effect as we've been discussing (Han, feel free to correct me if I'm wrong).

(12-30-2014 10:00 AM)Gilles Wrote: In my opinion, the '.' is ->NUM and not EVAL.

Yes, it seems ->NUM is more appropriate.

(12-30-2014 10:00 AM)Gilles Wrote: I would like this but the disadvantage is that the ~ is not directly on the keyboard with only a keypress on the contrary of .

That's important. we'd have to find a non-shifted key to dedicate to ~, versus the dot being readily available and physically close to the numbers.
What about the numbers? Do we display 4~?
3 INV -> 0.3333333~
or perhaps prefix:
3 INV -> ~0.3333333 (I like this, more mathematically correct)

Do we use ~f(4) or f~(4)? I think prefix is perhaps better.

One more thing in favor of the dot: on a proportional font (which newRPL uses), a dot only takes 2 pixels wide, versus the ~ symbol taking 4 or 5 pixels.
'3~*X^2-pi~'
'~3*X^2-~pi'
'3.*X^2-pi.'

The expression above looks much shorter with the dot (at least in my browser).

So we have:
* Keyboard accessibility: dot is better
* Screen space: dot is better
* Readability (and clarity of intent): ~ is better
* Mathematical correctness: ~ is better

It seems we are tied 2-2. Any other tie-breaker comments anyone?

(12-30-2014 10:00 AM)Gilles Wrote: Another thing, I like that uppercase and lowercase are not the same thing in commands and functions in RPL.
But i would be pleased if all the native commands and functions in newRLP will use lowercases instead of uppercases : start next , for next , cos, sin ... (or Start For Next Cos, Sin) are more readable and less agressive than START NEXT or FOR NEXT COS SIN

That wouldn't be a problem, it's relatively easy to change. The First-Letter Capitalization looks good, but it'd force you to change CAPS mode very often (extra keystrokes).
So we are between full lowercase and full uppercase. I think we need to hear more opinions in this matter before making a decision. I'm neutral, as uppercase doesn't bother me, but I'm also used to lowercase from C.

**rprosperi** · 12-30-2014, 02:26 PM

(12-30-2014 10:00 AM)Gilles Wrote: By the way, the unary operator ~ suggested by Han seems the same as ->NUM. I like this ~ notation.

I agree that the ~ notation is preferred over the trailing dot. In RPL, dot is used frequently and for many things already, so IMHO it's best to use a new notation such as ~ to keep the intended use unambiguous, even if it is possible to add the trailing dot notation to an already complex parsing process.

Just one man's opinion.

And thanks Claudio, Han, etc. for the interesting glimpses into the evolution of newRPL. Rare to see the conceptual and design process evolve as it happens.