thread repost: Discussion on Parser/UI Options

[Manolo Sobrino]

(04-04-2014 09:06 PM)Han Wrote:  No, it doesn't. It only knows that y is defined to be x.

Now we are nitpicking, well, it knows that y <- x, (what is exactly the type of the answer? Is it a text string?)

(04-04-2014 09:06 PM)Han Wrote:  

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.

That's my whole point, it would be nice that it knew what to do with undefined variables. If you input x in Mathematica, Giac/Xcas, Derive, the competition... you get a printed x. (Reduce is nicer, it asks you whether you want to define an operator Y/N. If you say no it prints x, if you say yes, it's x(x) ). I know the idea is keeping an independent numerical environment, but having the capability to work with undefined variables (or being able to deal with defined symbolic variables without having to evaluate them) is a must if you want a seamless integration with a CAS... but YMMV. As I said, I think that you can get that functionality if you parse any expression with undefined variables and send it to the CAS/call evalf(), and then print results.

(04-04-2014 09:06 PM)Han Wrote:  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.

I was just giving an example of a CAS that has implied multiplication. They went for brackets for function values, and that is a great thing for consistency, because using parentheses is just a typographic ambiguity that context resolves, even when they are used for wildly different things. When you give instructions to a computer it is a very good idea to establish the set of arguments of a function with a different syntax than that of a vector, an open interval, or a particular order of operations.

As I said, I think it's a personal choice. IMO it's just that most people are used to environments that understand both 2(1+2) and 2*(1+2), it's no big deal really.