#### abstract algebra impossible in maple? (20.12.02)

The dot product on Maple ( ’.’ operator ) has no eﬀect upon undeﬁned objects, even if the eﬀect of such
operation may depend only on the conmutative properties.

a desired capability would be the following:

>(A + t*B).(A + t*B);
(A + tB)(A + tB)
>expand(%);
2 2 2
A + 2 A t B + t B
>collect(%,t) assuming commute(t,[A,B]); (t commutes with A and B)
2 2 2
A + t(BA + AB) + t (B )

currently this doesnt seem to be possible

Other thing that ’should’ be easily computable but seem to not be implemented yet is bra-ket
formalism

ie:
> <psi|:=a*<e1| + b*<e2| + c*<e3|: //(a basis)
> expand( <psi|rho> );
a*<e1|rho> + b*<e2|rho> + c*<e3|rho>
> Projector:= |psi><psi|:
> Projector.|psi>;
_ _ _ _ _ _
( a*|e1> + b*|e2> + c*|e3> )*(aa<e1|e1> + ab<e1|e2> + ac<e1|e3> +
_ _ _ _ _ _
ba<e2|e1> + bb<e2|e2> + bc<e2|e3> + ca<e3|e1> + cb<e3|e2> + cc<e3|e3>)
>% assuming(real,a,b,c), additionally( orthonormal, |e1> , |e2> , |e3> );
2 2 2
( a*|e1> + b*|e2> + c*|e3> )*(a + b + c )

But again, this doesnt seem to be possible, and im not aware what language resources are available to
Maple to implement it. Any hints about this?

| a desired capability would be the following: ...

Huh? This is only valid if A commutes with t*B and t commutes with B. You should get
A.A + A.(t*B) + (t*B).A + (t*B).(t*B).

It is true that expand does not do anything with ”.”. Here is at least a partial remedy:

| >collect(%,t) assuming commute(t,[A,B]); (t commutes with A and B)

It would be ”commute”.

> The dot product on Maple ( ’.’ operator ) has no eﬀect ...

Dot is speciﬁcally deﬁned to be non-commutative unless one of its operands is explicitly numerical.
However, one way to make . commutative in Maple 8 is as follows (which should work in all versions
since Maple 6):

> use `.`=`*` in
> (A + t*B).(A + t*B)
> end use;
2
(A + t B)

> Other thing that ’should’ be easily computable ...

Since Maple 6, the read syntax <...|...> is used to represent a row vector, so it could be used for
bra-ket notation only if there were some mechanism for redeﬁning read syntax and I’m not aware of any
such mechanism.

Customization of the read and print facilities is an area in which Maple is weak compared with other
CASs (such as REDUCE). If you are prepared to use a diﬀerent read syntax, such as bra and ket as
functions, then it should not be too hard to implement the formalism. You could overload . in a module
to implement the various non-commutative products involved.