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

[William Sit]

Bill:

Rather than reply to your ??? point by point, what I was trying to say is that
in a set X equipped with several (let's say three) operations each of which
(with appropriate "unit" element that I ignore for simplicity) makes the set
into a monoid, these three operations can be notated, say, *, +, o, and these
are programmed in the domain constructor X using three formulas (but without
looking at the code, you won't know which formulas are used or which matches
with a particular notation). Assume that these operators are not following any
particular convention (so if X is a set of real-valued functions on a finite
field, * could mean 'max', + could mean pointwise multiplication, and o could
mean pointwise addition). Of course, there could also be some other set Y, say
also a set of real-valued functions defined on a (perhaps different) finite
field, with the same set of three monoid structures, but they may be notated
differently! Now if some domain, such as X or Y, has been passed to a subroutine
we are writing, but we don't know which, and let's say in the routine, this is
called Z. We know Z is going to be a set of real functions on some finite field
and we know there are three operations: adding functions, multiplying, or taking
the max. But Z could be either X or Y and which one it is can only be known at
run time. Say in the routine, we want to do a pointwise multiplication, no
matter what Z is.

   If Z has Monoid(*$Z) then ...

Is there ANY definite meaning to the *$Z?  If you say you are writing generic
code, you would have to, as Ralf said, test every possible name for pointwise
multiplication. To avoid this, you need "*" be the ONLY (default) notation for
pointwise multiplication. This contradicts Martin's idea, which is specifically
to allow arbitrary notation (namely, operator).  So Z may be the tri-monoid X
with pointwise multiplication, but not use * for this operation, and use * for
max.  Or Z may be the tri-monoid Y. How would you know what operation is in the
definition of the monoid (Z, *) without knowing Z = X or Z = Y AND reading the
domain constructor code for *? The only way for such code testing to make sense
is to follow a convention that * in a monoid has only one meaning.

In Mathematics, we know what (Integer, *), (Integer, +), (Integer, max) mean
unambiguously because these notations *, +, max have their fixed usual meaning,
by convention. This convention avoids us having to look up the meaning of the
operations. Since you must unambiguously know the meaning of an operator when
you test, you must fix this convention. But once this convention is fixed, then 
'Monoid(+$Z)' just becomes another way of saying AbelianMonoid.

William


"Page, Bill" wrote:
> 
> On Monday, March 13, 2006 2:39 PM William Sit wrote:
> > ...
> > 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.
> 
> ??? I thought that was precisely what Martin wants this
> to mean. Obviously '*' is the operator in question. More
> precisely one might write:
> 
>     If X has Monoid(*$X) then ...
> 
> > 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.
> 
> I don't think any "guessing" is involved.
> 
> > 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.
> 
> ??? I don't think what you wrote above makes sense. Obviously
> the program does "know" what X is. It has presumably been
> passed from some other part of the program or from the user
> via the interpreter. But the point is we do not want to write
> code that is specific to X but rather code that will work
> provided that X has a monoid structure with the binary
> function *$X.
> 
> >
> > 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.
> 
> No! This is exactly what Martin is trying to avoid.
> 
> > But really, there is really no need for such proliferation
> > unless many descendents are anticipated.
> 
> I think Martin's point is not so much related to a specific
> programming need, but rather to the desire to write code
> that corresponds to common mathmatical usage.
> 
> >
> > 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).
> >
> 
> In fact in Axiom with SPAD default implementations in
> categories are implemented as a package with a special
> name related to the name of the category.
> 
> Regards,
> Bill Page.