CAS command question

[Han]

(01-04-2017 08:37 PM)DrD Wrote:  Both of Arno K's comments are fitting, but I was referring to his first, "left is left, and right is right" comment. That says it all. The user solving the example problem would not need to be concerned about the intrinsic system level details, and can input the expressions as found, no need to worry about evaluation, format, or other internal concerns. Even more so, if tasked with creating a program solver for this example.

And this is the biggest pitfall for any CAS user. Mathematica uses f[x] for functions whereas Maple uses f(x). But then writing f(x)=x^2 in Maple doesn't actually create a function. In fact, functions are represented as name := (var) -> expression (like the Prime). Some systems use 0-based indexing and others use 1 as the starting index (and this varies even from country to country; I think the EU normally starts sequences at 0 whereas there is not a consistent convention in the US). This is why I make it a point to teach my own students that the first thing to using a CAS is knowing how it represents its objects. This is especially important when programming with a CAS.

When a user types f(2), should this be literally f(2) unevaluated? Or should the system return 4 if f was previously defined as f(x):=x^2? Being able to properly deal with symbolic input that has many equivalent forms is not trivial from a programming point of view, even though it is quite trivial mathematically. More relevant to our discussion, if x:=(a+b<c) then should x be treated literally as the symbol 'x' or should it be treated as equivalent to a+b<c? This is a simple yet important question because left(x) -- as you prefer it -- could either return a+b or give an error because the symbol x itself contains only a single letter and no "left hand side" (or "right hand side"). From a user point of view, it seems almost obvious that when we type left(x) we mean for x to be replaced by a+b<c. Except it is completely non-obvious from a programming point of view.

For what it's worth, Maple's lhs and rhs commands behave almost exactly this way (at least in Maple 17, anyway) except they prefer < and <= over > and >=. From their documentation:

Quote:There are three internal data types for inequalities, corresponding to the operators <>, <, and <=. Inequalities involving the operators > and >= are converted to the latter two cases for purposes of representation. An inequality has two operands, the left-hand side and the right-hand side. The names <>, <, <= are known to the type function.

The real problem here is not really about left/right -- in fact, the more I play around with them, the more I lean toward thinking that they are perfectly consistent in behavior and even properly named (see earlier post on how expressions are represented). The "only" problem I see here is that in the lack of documentation. The Prime's CAS documentation (and even non-CAS documentation) is unfortunately always lagging behind the feature-set.

For parisse: I honestly do not know of a good documentation system this late in the game, and one that comes to mind may be a bit too late: doxygen. Comments are turned into online documentation and one can embed mathematics code such as LaTeX. You probably know about it, but for those who don't -- it basically strips comments from source code and turns it into documentation. That way programmers can keep everything in a file and not have to write documentation in a separate file. I suppose one could go back and add in comments into the source code.

EDIT: forget what I said about doxygen; I misread what you mean for documentation.