Below you will find an example of insensible design of mathematical structures in Maple. This is a pity, since Maple should take care especially about notation, since a wrong notation gives wrong prejudices and may cause even serious errors and prevents Maple from being a valuable tool in education.
Maple offers &(ampersand) operators working as a type of products. They do possess a
prefix form &op(a,...,b) and an infix form (hence ’product’) a &op .. &op b.
While the prefix form is pretty good in distinguishing its arguments, the infix form is very insensible.
The below given example is from Maple 5.1, but it can be reproduced in Maple 7 also.
We define operators &f and &s (the later was intended to be a tensor product, hence being flat, multilinear, but this does not conflict with our claim).
This operator (function) can take a sequence of arguments, which reads in the prefix form
&f(a1,..,an). Arguments are clearly separates in such a type of sequence.
BUT! in the infix form &f has to *decide* what it takes as arguments. However, this depends on the definition of the operator &f, and its assumed behaviour. The only pretty save way to implement this is to take any expression until the end of the expression or a second occurrence of &f. However, &f decides *wrongly* to take only the next *factor* !
Let &f be any operator:
&f(a+b,c+d) = (a+b) &f (c+d) and no simplification should take place, but
Maple (5 and 7) decide to produce
>a+b &f c+d; a + ( b &f c) + d
which is nonsense since the operator is not allowed to do anything with its arguments which could be sums also.
Let &s be a linear associative (flat) operator, it ill-behaves in the same way with respect to the product.
> restart: > define(`&s`,flat,multilinear):
we consider infix form expressions of &s
> a &s b &s c; &s(a, b, c)
OK, that was easy, since nothing was to do,
BUT:
> a*b &s c*d; a (b &s c) d
NOTE the difference to
> (a*b) &s (c*d); a b &s c d
Moreover, &s is not aware, what it should treat as a second factor
> a &s b+c; (a &s b) + c
while it should come up with
a &s b + a &s c
since we assumed multi-linearity.
From the help-pages one learns that '&' binds stronger than anything but .
(respectively ||),::,% BUT that belongs only to the name of the operator, i.e. one has
not to write (&s) for the operator itself. (See online help to precedences).
The laconic comment of the Maple online help to '&' that ’Maple imposes no semantics (i.e.
sense) on the neutral (i.e. &) operators’ should be accompanied by the statement that it puts
no syntax either.
This behaviour is much more annoying in the case of a ’defined’ operator, which is supposed to behave e.g. flat and multilinear. Beside further problems with define, this makes this device very peculiar if not useless (for products, i.e. &(ampersand) operators).
E.g. a tensor product defined in this way needs a user who is aware of its properties. A student will fail to use this function or to learn from a robust behaviour of such a function what a tensor product can do and what not.
BUGFIX: The *intelligent* user sets parentheses where Maple does not know about the fact, or uses *exclusively* the stable prefix form.
A partial observation: Maple has a priority sequence for the exercise of operators: the
following execution of operators indicates that Maple ignores spaces in operator performance
and treats $f as higher on the priority list than +:
>a+b &f c+d; a + ( b &f c) + d
This explanation seems to fit some other anomalies quoted.
Yes, I agree with your observation. However, the *define* utility of Maple suggests to use &(ampersand) operators (see online help-page). These operators are assumed to have no preassigned assertions like being associative, commutative, linear (in the first argument) or multi-linear. Regarding the above given example, the infix form does not make any sense with the define facility. This was the meaning of our posting.
Indeed, we stated already there that using parentheses is a ’bug fix’ for this problem. However, it is annoying from a mathematical point of view and makes this device unusable in teaching (because you have to teach how the function works and students cannot test its behaviour since its not robust)
&(ampersand)anything should in its infix form take everything up to the end of input or the
next occurrence of an &(ampersand), this is possible, see e.g. the new ’error’ in Maple 6 and
7.