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

[William Sit]

Ralf Hemmecke wrote:
> 
> hi Martin,
> 
> On 03/13/2006 01:15 PM, Martin Rubey wrote:
> > Ralf Hemmecke <address@hidden> writes:
> >
> >> Hi Martin,
> >>
> >> a quick response to the following...
> >>
> >>> There is a simple practical reason why I dislike the idea of asking just
> >>> "Integer has Monoid".
> >>> Imagine I'm programming a package, and I need that a parameter domain M 
> >>> is a
> >>> monoid, so that I can use the monoidal structure, for example for
> >>> multiplying. Well, then simply asking M has Monoid doesn't buy me 
> >>> anything,
> >>> since I won't be sure that M really is a Monoid with respect to "+".
> >> Imagine you could ask "if M has Monoid(+)..." or "if M has
> >> Monoid(*)...". According to which returns true, you would then go on and 
> >> call
> >> (m1 +$M m2) or (m1 *$M m2). Well, but M might have a monoid structure with
> >> respect to the operation ".". Do you really also want to ask "if M has
> >> Monoid(.)..."? That soon becomes impractical.
> >
> > No, this is not an issue about practicality.
> >
> > Look at it this way: Suppose "M has Monoid" returns "true". How do you know
> > then with respect to which operation M is a monoid? What can you do with the
> > information that M is a monoid with respect to some operation?
> 
> If
>    Monodid: Category == with{ 1:%; *:(%,%)->%; }
> then "M has Monoid" means that M has a 1 and *.
> 
> By now, we all know that if "M has Monoid" returns false, it does NOT
> mean that M is not an object in the category of (mathematical) monoids.
> 
> It is as simple as this "Monoid" in Axiom does NOT stand for the
> category of all monoids.
> 
> Ralf

Martin:

If we are allowed to change the notation for the monoid structure so that a set
can have multiple monoidal structures and we can inquire about it, then some
code like:

   If X has Monoid("*") then ...

would have no definite meaning since you will NOT know the operator in X that
makes it a monoid. Even if you happen to guess the correct **notation**, you
still would not know what the **definition** of the operator is without looking
at the code for "*", manually, of X. In other words, you have NO way to know
when you write that code that the operation "*" that is matched (when 'X has
Monoid("*")' returns 'true') that it is the operation you have in mind in the
code following 'then' since by your testing the predicate, you admit that you
don't know what X is at run time.

The way this need to be handled is to use accepted conventions for different
types of monoid operations (and of course, we can't have it all, but whatever we
have in the system, it would be documented and uniquely named. So we can write
code with no ambiguity. Examples would be AbelianMonoid (using "+"),
CompositionMonoid (using \circ), MaxMonoid (using 'max'), etc. But really, there
is really no need for such proliferation unless many descendents are
anticipated.

If you want to avoid duplicating code, like 'square', we can define 
'square(m:%->%, x:%)' for any X:Type in a package. (This example can be
generalized clearly).

William