newRPL: symbolic numbers

[Claudio L.]

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.