#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues: merge with #15801
public/ticket/10963-doc- | once things stabilize
distributive | Commit:
Dependencies: #11224, #8327, | 8e83e4238ae83a829cbe1a1c4c4cfc5072224f72
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:572 darij]:
> I'll try to think of an example with quotients (that does not involve
schemes...). For direct products, for example the direct product of two
groups in the category of groups is their free product (
http://en.wikipedia.org/wiki/Free_product ), while the direct product of
two abelian groups in the category of abelian groups is their cartesian
product. If you have two abelian groups A and B, their direct product as
groups is not the same as their direct product as monoids, not even as a
monoid!
Yes! That's precisely why there is basically nothing about "direct
products" in
the category infrastructure: the fact that it's not covariant (aka
uniform across categories) means there is nothing we can share
automatically. This is unlike cartesian products or quotients!
Just to state the obvious about the covariance for quotients (or
equivalently homomorphic images): take B a subcategory of A, and Y an
homomorphic image in B; since B-morphisms are A-morphisms, Y is also
an homomorphic image in A).
> > It's a finite semigroup (the "finite" was missing above; I just added
> > it and will push later on). So implementing the product and the
> > semigroup generators is one of the ways to define everything. Another
> > way would indeed be to provide `__contains__`.
>
> OK, but is this necessary? What exactly is the promise that is being
fulfilled?
I tried to improve the phrasing. Please check.
> I know -- but it is hard to review something without understanding more
fundamental things!
Fair enough. Let it be Christmas! Done.
> > > - The primer mentions `Sets().Algebras(QQ)` as an example. What
exactly does this mean? The repr string ("Category of set algebras over
Rational Field") isn't very helpful,
> >
> > Agreed. The "right" piece of documentation is in
> > sage.categories.algebra_functor.AlgebrasCategory. This documentation
> > should really be in Sets().Algebras but this is unrelated to this
> > ticket and should be fixed elsewhere. Feel free to open a ticket!
>
> I don't understand. My original point was that these algebras appear as
examples in the doc of the categories framework, and needlessly confusing
examples should be removed/replaced. But now I've gotten really curious
what a set algebra is! I assume the lack of doc is a good reason to open a
new ticket, but what exactly should I suggest in that ticket?
Oh, I see your point now. Ok, that can be easily
improved. Done. Please check!
> The problem is that "whose objects are objects in C" is meant literally
here, not in the sense of "whose objects have a C-structure (among other
data)". A graded algebra is a graded module, but it also carries a
multiplicative structure. This would not be possible if the category of
graded algebras were a subcategory of the category of graded modules.
(When you look at the "formal definition" on wikipedia, it says that "A
subcategory S of C is given by
>
> * a subcollection of objects of C, denoted ob(S),
> * a subcollection of morphisms of C, denoted hom(S)"
>
> satisfying several axioms. This does not leave any space for additional
structure on the objects.)
Ah, interesting, you are the first one to raise this point :-) So far,
I was taking for granted that it was natural to consider the
additional structure as being "encoded" in the morphisms. Ok, we
probably need to clarify this, even though we are just following the
terminology that is in use in other systems like Axiom, ...
> That said, why the focus on full subcategories? Fullness is a property
of morphisms, and as far as I know morphisms have not been used very often
in Sage so far (and there are issues like #15381 that make their use
dangerous). Do you have any applications in mind for full subcategories as
opposed to any subcategories?
Yes indeed! One of the very next steps is precisely to improve the
support for morphisms (see #10668). And without the full subcategory
business, there is not much homsets stuff to inherit and share between
categories.
> Unital magmas are not a full subcategory of magmas! A morphism of unital
magmas is not any arbitrary morphism of magmas, but a morphism of magmas
that preserves the unity. I've seen textbooks getting this wrong, so I'm
not surprised here, but please fix this before it can cause damage to
Sage.
Ah right, I had thrown this under the carpet so far, but it probably
needs to be uncovered a bit.
The point is that often, in practice, what's useful in similar
situations is actually the full subcategory, even if mathematically
speaking the natural category is not the full one. For example, for
ModulesWithBasis (modules with a distinguished basis), we definitely
want to use the distinguished bases to compute with morphisms. But
restricting to morphisms that preserve the distinguished bases would
be really boring.
I haven't made up my mind about the proper way to handle this; as you
mention above this is currently rather harmless because there isn't
that much generic stuff for morphisms.
But I see your point; it's probably best to not get into the details
until things are settled by just not using the "full subcategory"
terminology; I have started doing this in the primer, and will have to
check about this elsewhere.
> That's fine, just please add a sentence about this. A good place seems
to be after line 1142 which says half of it. Generally, are the names of
the operators in axioms hardcoded? If so, that would be good to point out
lest the reader expect more polymorphism than is there.
Done. A full note actually, inspired by the discussion above. Please
check.
> Nice! (I probably can't make up my own mind about this, since reading
the whole source is over my head.)
Just to make sure: I just meant the main docstring of Category.
Thanks again for the useful discussion!
Cheers,
Nicolas
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=8e83e4238ae83a829cbe1a1c4c4cfc5072224f72
8e83e42]||{{{Axioms: primer: specifying the category of a parent and using
it to add code + promise thingy}}}||
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:589>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
