[Haskell-cafe] Re: categories and monoids
ekmett at gmail.com
Thu Mar 19 08:58:58 EDT 2009
I've been thinking a lot about these issues lately, mainly because I have
been working with a toy compiler that uses multiple inheritance heavily, and
which uses adjectives explicitly for context sensitive mixins.
An easier idea to think about would be to categorize most adjectives applied
to mathematical constructs into traits and cotraits.
A trait refines a notion and a cotrait broadens the definition.
When talking about a commutative ring, commutativity is a trait, it narrows
the definition of the ring, adding a requirement of commutativity to the
When talking about semi rings, semi is a cotrait. It broadens the definition
of a ring, removing the requirement that addition form a group, weakening it
to merely require a monoid.
In that setting 'generalized' as applied in the scenarios mentioned is just
a cotrait. Its not wrong, its just not the more common notion of refinement
you are used to when seeing adjectives applied to mathematical primitives.
Whether traits or cotraits are applied when generating a new idea tends to
be a function of primacy. Sure, perhaps every field should be viewed as a
specialization of term for non-associative-field adding associativity, but
often we don't find out that these weakened notions are even meaningful
under after the more constrained topic has gained wide adoption.
Neither notion is necessarily more correct than the other. Abstract algebra
can be taught bottom up from groups to fields and beyond or 'top down' in
the more traditional manner by progressively weakening the definition of a
field. Eventually you wind up having to go both ways. After all if you
started 'bottom up' from groups, you've probably got to go back and work
down through monoids and semigroups to magmas if you want to be pedantic
On Thu, Mar 19, 2009 at 6:43 AM, Wolfgang Jeltsch <
g9ks157k at acme.softbase.org> wrote:
> Am Mittwoch, 18. März 2009 15:17 schrieben Sie:
> > Wolfgang Jeltsch schrieb:
> > > Okay. Well, a monoid with many objects isn’t a monoid anymore since a
> > > monoid has only one object. It’s the same as with: “A ring is a field
> > > whose multiplication has no inverse.” One usually knows what is meant
> > > with this but it’s actually wrong. Wrong for two reasons: First,
> > > the multiplication of a field has an inverse. Second, because the
> > > multiplication of a ring is not forced to have no inverse but may have
> > > one.
> > “A ring is like a field, but without a multiplicative inverse” is, in my
> > eyes, an acceptable formulation. We just have to agree that “without”
> > here refers to the definition, rather than to the definitum.
> Note that you said: “A ring is *like* a field.”, not “A ring is a field.”
> which was the formulation, I criticized above.
> Best wishes,
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe