William, On Monday, March 13, 2006 6:55 PM you wrote: > ... > 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, ... >
Ok, I think I understand your example. > 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. > > ... > Say in the routine, we want to do a pointwise multiplication, > no matter what Z is. > > If Z has Monoid(*$Z) then ... No. I do not see the conditional above as implementing code to do such specific things as pointwise multiplication. > > Is there ANY definite meaning to the *$Z? No. There is no such definite meaning. If Z has Monoid(*$Z) then ... only means that the operation *$Z is a monoid operation, i.e. that it is associative and that there exists an identity in Z. With this knowledge alone we can do only certain very limited things mostly involving algebraic simplifications or other manipulations, e.g. replace (a*(b*c)) with ((a*b)*c) etc. which might be useful in some contexts. Of course it might be more powerful when combined with other information about '*$Z' and it's relation to other operations. > If you say you are writing generic code, you would have to, > as Ralf said, test every possible name for pointwise > multiplication. No. I presume that in the code where the above conditional is used, we already know that we are interested in '*$Z' for other reasons, e.g. it's occurrence in a particular sub-expression or something like that. > 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). I don't think that is Martin's idea. The point is first and foremost to have a single implementation of the mathematical concept of 'monoid' independent of any other possible properties. In Axiom, as it exists now we could do this just by using declarative axioms such as: associative(*) which can also occur on the right-hand side of 'if ... has ...' except that in this case we do not get to do nice things like providing default implementations and we cannot relate categorical structures like monoids and groups to rings etc. and we cannot use this to specify algebraic signatures. I see what Martin (originally based on Gaby's question) is suggesting as an extension of Axiom's "axiom" and category system to be more expressive of mathematical structure. > ... > 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. > No. Convention is just that: a convention. We do not really know anything by the use of a particular symbol alone; but of course we might suspect that it has something to do with addition in some ring since it is annoying if someone flaunts a convention for no particular good reason. Something is an AbelianMonoid if its monoid operation (whatever it is) is commutative. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
