Re: [Axiom-developer] Curiosities with Axiom mathematical structures

[William Sit]

 "Bill Page" <address@hidden> writes:

 [...]

> | I don't think there is any essential reason why SemiGroup and
> | Monoid could not be implemented in the way you suggest. For
> | example:
> |
> | )abbrev category SGROUP SemiGroup
> | SemiGroup(m:Symbol): Category == SetCategory with
> |       m: (%,%) -> %    ++ returns the product of x and y.
> |       associative(m)
> |
> | )abbrev category ABELSQ AbelianSemiGroup
> | AbelianSemiGroup(m:Symbol): Category == SemiGroup(m) with
> |       abelian(m)
> |

Yes, there are no theoretical reasons, but there are plenty of practical ones.
I think such constructs will make it more difficult for the Interpreter to work
since it would not be able look up the appropriate signature from domains that
have not been instantiated during the session. Of course, if the Interpreter
knows what to instantiate, that won't be a problem. But how will the Interpreter
be able to know?  Indeed, how is a user to know what symbol was used, say, for
the operations? What if the user instantiates Integer with both * and + for the
same operations in two instances? Can a compiler or interpreter catch this? If
not, it would be a nightmare of bug reports.

By allowing renaming of operations (even just all binary operations), the
categorical notation for * or + no longer exists and it would be impossible for
the Interpreter to search for a suitable signature in a categorical manner ---
only on a specific domain by domain (and for instantiated domains only for that
matter) basis.

I do recognize some limitations for having two monoid categories structured on
two different operator notations. For example, there is no commutative monoid
with * as the multiplication and these are needed (if one wants to look at the
set of monomials in several variables as a multiplicative monoid). However, it
is far easier to have say, AbelianAdditiveMonoid and AbelianMultipicativeMonoid
categories (cf. one AbelianMonoid where the operator must be "+") than to
implement all operators used in algebras as parameters. For CAS to be practical,
certain compromises are necessary. I do not question the theorectical advantage
of rebuilding all algebra based on properties of operators (there is research in
theory of operads which would support such a design) but I doubt their
practicality, especially when the notation for the operators can only be known
dynamically at run-time.

As already well-known, with the current status, all properties of operators are
declarative and not verified. There is a certain degree of trust that users know
what they are doing. Creating examples that deliberately violate these
conventions and implicit assumptions of the system and show the "weakness" or
"buggiess" of Axiom (or any other CAS) is not productive. One consequence of
these examples is confusion of the real issues: the lack of documentation on the
conventions and implicit assumptions, and real bugs.

William