+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: Not HP Calculators (/forum-7.html)
+--- Forum: Not quite HP Calculators - but related (/forum-8.html)
+--- Thread: newRPL: symbolic numbers (/thread-2697.html)
Pages: 1 2
RE: newRPL: symbolic numbers - Han - 12-30-2014 04:50 PM
Full disclosure: I have not read the entire thread in full detail. The suggestion regarding ~ is explained below, mostly divorced of the pre-existing discussion.
The ~ notation isn't just a replacement for the secondary decimal point, which in my honest opinion is not a good idea. I don't think Y. should evaluate whatever is stored in the variable Y; in the HP48/49/50 series, Y. is a valid symbol (for a global variable). It should remain that way as never before have we allowed an operator to be attached to a symbol -- without spaces. This also means we don't have to worry about the meaning of Y.X -- is that a variable or is that Y. X (like how the HP48 allows 2+ to mean 2 +)?
The ~ symbol is a hybrid operator/delimiter/constant declarator with a prefix notation. It behaves exactly like the "\( - \)" symbol in that it can both be an operator or used to designate an approximate value. For me, the notions of exact and approx should be limited to only symbolic objects. This allows us to "collect" approx and exact terms and keep them separate. Outside of that, everything should just be a number and whether the fraction mark is displayed for numbers with "essentially" no trailing fractional part is relegated to a system flag. This also implies that '1' is a valid symbolic object. On the HP48 I believe it auto-simplified to just 1 (DOREAL as opposed to a composite DOSYMB containing a DOREAL).
Examples:
'~2.5+6.6-5' EVAL returns '~2.5+1.6'
'~2.5+6.6-5' ->NUM returns 4.1
'~2.5 * 2' EVAL returns '~2.5 * 2'
'~2.5 * 2' ->NUM returns 5. (or just 5 depending on the show-fraction-mark system flag)
2 ~ returns 2 or 2. (system flag)
'2' ~ returns '~2'
'2.5+5' ~ returns '~(2.5+5)'
'2.5*2+~3*(.5+~6)' EVAL returns '5+ ~3*.5 + ~18'
'2.5*2+~3*(.5+~6)' ->NUM returns 24.5
In the long run I think it will also make it easier to implement solvers (numerical or symbolic).
Edit: I suppose if you also want to implement using the fraction mark as an indicator for non-integers (outside of the the symbolic environment) that would be fine too.
RE: newRPL: symbolic numbers - Claudio L. - 12-30-2014 07:18 PM
Let's explore the consequences of your proposal:
(12-30-2014 04:50 PM)Han Wrote: The ~ symbol is a hybrid operator/delimiter/constant declarator with a prefix notation.I like prefix for this symbol.
(12-30-2014 04:50 PM)Han Wrote: It behaves exactly like the "\( - \)" symbol in that it can both be an operator or used to designate an approximate value. For me, the notions of exact and approx should be limited to only symbolic objects.
I thought that way at first, but when you assemble a symbolic object from the command line it becomes a pain to type quotes, then the approx. operator, then the number:
3 'X' * 5 + --> '3*X+5'
If you want the 3, 5 and X to be approximated you'd have to type:
'~3' '~X' * '~5' + --> '~3*~X+~5'
or
3 ~ 'X' ~ * 5 ~ + --> '~3*~X+~5'
In other words, a symbolic with aprox. numbers/vars can only be assembled from other symbolics with the proper operator, never from existing numbers.
(12-30-2014 04:50 PM)Han Wrote: This allows us to "collect" approx and exact terms and keep them separate. Outside of that, everything should just be a number and whether the fraction mark is displayed for numbers with "essentially" no trailing fractional part is relegated to a system flag. This also implies that '1' is a valid symbolic object. On the HP48 I believe it auto-simplified to just 1 (DOREAL as opposed to a composite DOSYMB containing a DOREAL).
Examples:
'~2.5+6.6-5' EVAL returns '~2.5+1.6'
'~2.5+6.6-5' ->NUM returns 4.1
'~2.5 * 2' EVAL returns '~2.5 * 2'
'~2.5 * 2' ->NUM returns 5. (or just 5 depending on the show-fraction-mark system flag)
2 ~ returns 2 or 2. (system flag)
'2' ~ returns '~2'
'2.5+5' ~ returns '~(2.5+5)'
'2.5*2+~3*(.5+~6)' EVAL returns '5+ ~3*.5 + ~18'
'2.5*2+~3*(.5+~6)' ->NUM returns 24.5
From these examples I see you want it to work more like a "tag" to create a separate class of numbers, since you don't allow approximated numbers to be operated with exact numbers (unless ->NUM is used, which ignores the tag). This operator is a NOP, only tags an object and tagged objects can be operated together as a group.
I don't like the fact that it prevents some obvious operations from being executed. I'd expect '~2.5*2' EVAL to give me '~5', then ->NUM give me the number 5 (no longer symbolic).
What about variables?
if X contains the expressions in your example above:
'~X' EVAL --> ??
(12-30-2014 04:50 PM)Han Wrote: In the long run I think it will also make it easier to implement solvers (numerical or symbolic).
On a numeric solver, you'd have only numbers, versus having exact/approx numbers in the trailing dot proposal. The trailing dot (or ~ symbol) from the previous proposal is implemented as a bit in the prolog of the number. A numeric solver can simply ignore this bit, so there's really no overhead there. If we look at evaluating an expression, a variable tagged with your ~ would have to execute ->NUM, just as the previous proposal, and the tag in numbers can be ignored (same as in the other proposal with the bit in the prolog).
So I think your proposal is roughly equivalent, except in one thing:
The previous proposal has any approximated number "eat" any exact numbers and give an approximated result.
Other than that, it's basically the same thing, internally implemented different.
Edit: Regarding this last remark: if approximated numbers cannot be operated automatically with exact numbers, then the "approx" mode cannot be emulated, and also the effect of flag 3 cannot be emulated from within the expression. This means this operator does not achieve the goal of eliminating the exact/approx modes and associated flags.
There's also one big disadvantage with having it implemented as an operator vs attached to the number/identifier: a rules-based engine will not be able to see through the operator, so every rule will have to be duplicated, with and without the "approx" operator. If the approx. condition is defined as a property of the number/identifier, then the same rules apply regardless of whether a variable is exact or approx.
RE: newRPL: symbolic numbers - Gilles - 12-30-2014 10:18 PM
(12-30-2014 04:50 PM)Han Wrote: (...) It should remain that way as never before have we allowed an operator to be attached to a symbol -- without spaces.
Han, I understand your point of view but 'It should remain that way as never before we...' is not a good argument.
I remember RPL+ of Oliver Unter Ecker. He use for example these kinds of syntax :
5 =A as an alternative to 5 'A' STO
5 =+A as an alternative to 5 'A' STO+
++A as an alternative to 1 'A' STO+
Less keystrokes and better lisibility in my opinion. Just a question of parser. I don't see any problem here.
By the way, if M is the matrice [ [ 1 2 ] [3 4] ], you can do with the 50
`M(1,2)` instead of { 1, 2 } 'M' GET
or
`M(a+b,c+d)` instead of a b + c d + 2. -> LIST 'M' GET
or
8 'M(1,2*c)' STO
so why no operator attached to a symbol ? Exemple :
M(1,2) @without space
M(a+b,c+d) @without space
8 =M(1,2*c)
2 =*M(a,b)
++M(a,b)
A B * =M
M =MyNewMatrix
'sin(a)+cos(b)' =f
If the parser can manage this in an efficiant way,I see only advantages in term of lisibility and efficiency.)
Perhaps postfix notation will be better. ( M+= etc.)
RE: newRPL: symbolic numbers - Claudio L. - 12-30-2014 10:39 PM
Summing up this thread, here are some clear items:
To eliminate the approx/exact system mode, and to be able to emulate all its possible variations from within an expression, we need:
a) Symbolic numbers
b) Exact/approx numbers
c) Exact/approx variables or expressions.
d) Approx must "eat" exact.
We explored two alternatives:
1) Exact/approx as a property of the numbers/variables: Can be seen as a flag or a "hint" for the numeric behavior of the number/variable for evaluation purposes only.
2) Approx as an operator: A fully defined prefix operator.
Option 1):
* The hint does not change the tree structure of the expression, so it's transparent to the CAS manipulations and rules.
* Solvers can choose to use or ignore the hint when evaluating the expression.
Option 2):
* CAS needs to work with the operator explicitly.
* The operator is transparent to non-CAS solvers when they evaluate the expression.
For user interface, two proposed symbols:
a) The trailing dot.
b) The ~ prefix.
Based on all the feedback, the best path seems to be Option 1) with a ~ prefix. A flag will also be included to use a trailing dot, for people familiar with TI, Mathematica, the HP50g and any other math software that already uses a trailing dot for approx. numbers.
Now it's time to start coding all this.
Thank you all for the feedback, I think we collectively came up with a very usable feature for newRPL. You should see it all working on the next demo release.
Claudio.