thread repost: Discussion on Parser/UI Options

[Han]

(04-04-2014 05:17 AM)Manolo Sobrino Wrote:  1) Go to CAS and define: y:=x

2) Go to HOME and input: y

Then the numerical CLI prints: x

That's very good because it knows that x=y.

No, it doesn't. It only knows that y is defined to be x.

Quote:3) input x

Then you get "Error: Syntax Error". Same error as if you hadn't defined y.

As it should. You only defined y as x. You never defined x as anything, so x is undefined. There is a good reason for this behavior. If you use y:=x, and then later issue the command y:=1, it should ONLY change y. Otherwise, you implicitly create a new variable x whose value is 1 if the system were to somehow assume that y and x are now the same.

Quote:The variable y has been created by the CAS, HOME knows about it, no problem. It knows that whatever is y, its value is x. But it doesn't know what x is!

And it would not unless 1) you've defined x to be some particular value and 2) you've requested the value of x. In the CAS, if you enter y:=x; and then x:=1; and type enter y by itself, it returns 1 because (as any good CAS would) it understands transitivity. In Home, the behavior is always "face-value" -- you only get what you ask for in the sense that if you want the value of y, it tells you that you that y is defined as x. There are instances where BOTH behaviors are useful. For example, if you need to know whether y is a symbolic variable or a numerical variable, having y return only x is useful. In the CAS, TYPE(y) and TYPE(x) would both return 0 if you type y:=x; and x:=1; and the same holds even if you use the CAS-specific lower-case form type(y) and type(x).

Quote:It's strange because at the Vars menu, x and y appear both as CAS variables. I guess Giac creates variables on the fly and the numerical environment doesn't.

Yes, provided that x and y were created/defined in CAS.

Quote:That is not that bad, because now we've learnt that we can move symbolic variables around environments by doing this... Say you want to get an expression with engineering-ugly numerical coefficients in terms of the variable x. Just do it with y. Quirky things happen then that I guess can be worked around with the approx() function. (Why Giac's evalf() and evalc() are not in the CAS menus is a mystery to me.)

You could do this with any variable; perhaps I am misunderstanding something...

Quote:About implied multiplication. Well, many people just expect it because it's nice sharing the conventions of blackboard-written maths with the syntax of the computer program you're using, even when we're just dealing with 1-d expressions. Mathematica does it and there is no ambiguity there. I think it's just a personal choice.

If you do it, you have to be consistent: The Giac interpreter version, that is CAS mode, understands x(1+x), but not (1+x)x. In HOME mode, in terms of the previously CAS-defined y:=x, interesting things happen (emulator) again:

(1+y)y is rendered immediately as: (1+y)*y ____________ (1+x)*x

y(1+y) as... y(1+y) ____________ x(1+x)

(Where are the *'s now??)

I agree with the consistency remark. I disagree that just because project XYZ does it that it is suddenly ok. Mathematica uses non-standard notation for functions. How many textbooks do you see use f[x] ? The typical notation is f(x). Now, what about x(t+1) -- should that be a function of x in terms of a parameter t? Or should we interpret that as a product of two expressions x and t+1 ? This is why there is no * in the second case. There is a reason for wanting explicit notation so that we can avoid instances of ambiguity. No CAS will be able to magically guess when a(b) should be multiplication and not functional notation.