Andrew U. Frank wrote:
> should * always be
> commutative or is its use for non-commutative types acceptable?
>This very question caused much agony in many design meetings for the CAS
Maple. The list of pros and cons on each side is quite large!
There are too many really nice optimizations that one can do with a
commutative, associative function (like * over commutative rings), and
these are expected to be performed if ``efficiency'' matters. Hoping
that the compiler will always be smart enough to tell that in case X or
Y, such an optimization is valid, is quite optimistic.
Until there is a way to encode that a particular instance of * is
commutative, and another is not, it is much safer to have two symbols.
Note that I would personally prefer a much larger set of classes, which
would include encodings of *properties*, so that one could (easily,
cheaply) declare some occurence of * as commutative by using the right
signature. That would really require some kind of class aliases to have
a hope of success. But such a large set of classes is understandably
too ambitious, and better suited to Haskell''. But for a taste of what
you get if you follow that route, see
http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/
and also
http://www-sop.inria.fr/cafe/Manuel.Bronstein/algebra/
for why the 'base' of the system needs to be complex to allow scaling.
Note that the above libraries are NOT optimal, as the authors went part
of the way to fully breaking down the algebraic hierarchy, but were not
prescient enough 10 years ago when the basic design was being laid down
to break it down all the way.
Jacques