thread repost: Discussion on Parser/UI Options

[Manolo Sobrino]

(04-05-2014 08:56 PM)Han Wrote:  The bracket notation is inconsistent with many other languages/CAS in which a[ i ] refers to the i-th entry of a vector. The point is that we as humans are completely capable of deciding whether a(i) refers to the i-th entry of a list or vector, a function named a whose input variable is i, or the product of a and i -- merely based on context clues. Even so, someone just learning about functions might not necessarily see the difference so clearly. What you are asking for is a CAS that is able to infer as well as a human -- not an easy order to fill. Maple, for example, does not allow implicit multiplication. Sure, when the operands are pure numbers it may be apparent. However, once you allow it for numbers people will naturally wonder about variables. As a simple example, is xy the variable named xy, or is that a product?

Well, you could use braces {}, as in LaTeX. S. Wolfram made his own choice:

http://reference.wolfram.com/mathematica...ectly.html

• parentheses: ( ), precedence
• brackets: [ ], set of arguments
• braces: { }, lists
  

It is consistent, logical, works and people like it once they get it. I don't have a use for Maple (nor an institutional license). I could argue strongly in favour of the Mathematica approach, the point of it is not really about implied multiplication... But then Mathematica has no awkward additional rules due to having to keep the function parentheses notation while using implied multiplication. Nice side effect .

It's too late to change the parentheses notation for functions (and nobody cares). Too bad, in my experience, the less typographical ambiguities we follow when teaching maths, the less hurdles for the student to truly understand them... Concepts should be distinctly introduced: try to ask the regular student why we write f(x) instead of f in a particular case.

As many systems with implied multiplication have sensible rules for variable names: any (practical) number of consecutive (not too weird) characters will do, just the first one can't be a number, there is no ambiguity:

• xy is the variable xy
• 2xy is just 2*xy
  

In Mathematica: x*y, x(y), (x)y and x y (space) are parsed as x y.


In Derive you have to define previously a function, say f, in order to have every instance of f(z) being understood as the value of function f for argument z. Then you have that f(z) is parsed as f(z), and you obviously can't use f without it's argument any more. If you did not define f before, f(z) is parsed as f·z, and (z)f as z·f. I think this approach makes sense. You can even define x(x):=x, if then you simplify x(y) you get y, if you simplify x(x) now, of course you get a "Syntax Error: Unexpected delimiter" as every x is a function and needs its arguments: x(x(y)) gets you y and so on.

Yet Derive has its own quirks. If you input xy it will print x·y. It takes to "define" xy as an unassigned variable: xy:= . After this, if you input 2xy it will print 2·xy, and if you input xy2 it'll print xy·2.

That IMHO, is a nice implementation that keeps the polysemous parentheses.

In the particular case I quoted, x(1+x) is parsed by Giac/Xcas 1.1.0 as x*(x+1) after a warning. It behaves the same way as, for instance, 2(1+x) ->/warning/-> 2*(x+1). While (1+x)2 results in a syntax error. But, in general, Giac/Xcas will understand that f(z) is a function f with argument z, so: y(1+x) is parsed as y(x+1). Maybe x(1+x) would be a recursive function or Giac thinks that things might go awry eventually (we'll see something like that in a moment), so I guess that Giac assumes that you'd better be multiplying it .

The TI 89 CAS is a simplified Derive. If you input 2xy it will print 2·xy. Now xy is just a token, as the undefined x was for Derive. x(y) is just a token too, it will print x(y), but interestingly x(x) gives you an error: "invalid implied multiply". I guess they thought that you might use that expression to define a function and you could run into trouble (that Derive syntax error), or they might want to protect your brain. Of course (x)y will print x·y.

And then, there are interesting mixed bags. Reduce has no implied multiplication, but performs happily arithmetic implied multiplication. That's cute, why not?

I see no strong arguments against or in favour of implied multiplication when it's well done. Both do the job. I find it convenient because I type less and obviously the operator is always there.

(04-05-2014 08:56 PM)Han Wrote:  The type depends on whether you use TYPE or type.

About the type... After defining CAS variables made out of gibberish, when the CAS variable is not a number etc, it's just whatever Giac will tokenize. Maybe I can make my point better: If the evaluation of a CAS variable gives you a CAS token in the numerical environment which you have no use for and you're happy with it, why don't tokenize in the numerical environment to begin with? Just treat any undefined variable (in the eyes of the unsuspecting user) with proper syntax as a token and don't evaluate it. If you can't do that, you could ask the CAS to do it, it's its job!

There's one thing that a new user understands less than getting x after typing x, and is getting "Error: Syntax Error". It will be impossible to hide Giac if you can't get 1.4142*x after entering sqrt(2)*x. (Just go and type sqrt(2)*y at HOME, or approx(sqrt(2)*x) at CAS, that's what the competition gets when they run in APPROX mode.)

As always, YMMV.