Threaded Mode | Linear Mode

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.