&(ampersand) operators, inﬁxform / complain (9.10.01)

Bertfried Fauser

Below you will ﬁnd 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 oﬀers &(ampersand) operators working as a type of products. They do possess a preﬁx form &op(a,...,b) and an inﬁx form (hence ’product’) a &op .. &op b.

While the preﬁx form is pretty good in distinguishing its arguments, the inﬁx form is very insensible.

The below given example is from Maple 5.1, but it can be reproduced in Maple 7 also.

We deﬁne operators &f and &s (the later was intended to be a tensor product, hence being ﬂat, multilinear, but this does not conﬂict with our claim).

This operator (function) can take a sequence of arguments, which reads in the preﬁx form &f(a1,..,an). Arguments are clearly separates in such a type of sequence.

BUT! in the inﬁx form &f has to *decide* what it takes as arguments. However, this depends on the deﬁnition 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* !

1. Let &f be any operator:

&f(a+b,c+d) = (a+b) &f (c+d) and no simpliﬁcation 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.

2. Let &s be a linear associative (ﬂat) operator, it ill-behaves in the same way with respect to the product.

> restart:
> define(&s,flat,multilinear):

we consider inﬁx 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 diﬀerence 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 ’deﬁned’ operator, which is supposed to behave e.g. ﬂat and multilinear. Beside further problems with deﬁne, this makes this device very peculiar if not useless (for products, i.e. &(ampersand) operators).

E.g. a tensor product deﬁned 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 preﬁx form.

Willard, Daniel Dr (15.10.01)

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 ﬁt some other anomalies quoted.

Bertfried Fauser (23.10.01)

Yes, I agree with your observation. However, the *deﬁne* 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 ﬁrst argument) or multi-linear. Regarding the above given example, the inﬁx form does not make any sense with the deﬁne facility. This was the meaning of our posting.

Indeed, we stated already there that using parentheses is a ’bug ﬁx’ 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 inﬁx 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.