#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:
public/ticket/10963-doc- | Commit:
distributive | 1cdc128a85851dd007b3b77ec53a4853a10e1de4
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by darij):
Thanks a lot for the explanations. I'll reply in more detail once I've
taken some more stabs at the doctest failure (high chances that it can be
fixed simply and in a separate ticket). Did you push your changes? I don't
see anything new. (Yes, pushing the doc higher up sounds like a good idea,
and is what I should have done. No, I'm not fixing docs of concrete
categories systematically; I just stumbled across these two and had to
look up Wikipedia to understand whether it's Semigroup or Monoid that has
the unity.)
Replying to [comment:569 nthiery]:
> Proofreading the documentation is an important piece of the review!
> And being in the target audience you are specifically fit for it. So
> thanks a lot!
You're welcome -- I'll need this ticket eventually.
> > - What do you do if you have a subcategory A of a category B, but the
notion of quotient objects in A is *NOT* a particular case (potentially
with some extra structure) of the notion of quotient objects in B ? (I
don't have any nice examples, but it's very easy to come up with examples
for the similar notions of "equalizer", "coproduct" etc.) Am I allowed to
override the `quotient` method on A? Can I expect that it will end up
being always used on objects of A and never used on objects of B?
>
> Not sure what you mean. I guess that would be easier to discuss on a
> concrete example.
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!
> > - primer.py around line 890:
> > {{{
> > This implementation specifies a data structure for the parents and the
> > elements, and makes a promise: the implemented parent is a
> > semigroup. Then it fulfills the promise by implementing the basic
> > operations ``product`` and ``semigroup_generators``. In exchange for
> > }}}
> > What promise does `semigroup_generators` fulfill? Why should a
semigroup always come with such a method? Isn't `__contains__` more of a
necessity?
>
> 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?
> It's appropriate to check that they are indeed in `self`, typically
> using `self.is_parent_of(a)`, and raise a value error otherwise.
Aha, thanks.
> > - These TODOs, particularly the first one, might be helpful to fill
out:
> > {{{
> > .. TODO::
> >
> > - Specifying the category of a parent
> > - Adding code to an existing parent
> > }}}
> > Particularly the first one sounds very important.
>
> Definitely. But there is already enough on the plate for this ticket!
I know -- but it is hard to review something without understanding more
fundamental things!
> > - 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?
> Well, you actually can provide documentation for them. But in most
> case it would be extremely redundant to have to do it, so we should be
> thinking about ways this documentation could be constructed
> automatically.
Yes, this really might be a task for a later patch.
> > - The notions of "subcategory" and "full subcategory" used in the
> > primer (and probably in the rest of the doc?) conflict with
> > mathematics. A subcategory in accordance with mathematical notation
> > cannot have any extra structure unless it is predetermined by its
> > existence (like inverses in groups). If you want to keep to this
> > usage of the notion in Sage, PLEASE HEAVILY DOCUMENT IT.
>
> Really? I used those definitions from
http://en.wikipedia.org/wiki/Subcategory:
>
> ``In mathematics, a subcategory of a category C is a category S whose
> objects are objects in C and whose morphisms are morphisms in C with
> the same identities and composition of morphisms''
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.)
> ``A full subcategory is one that includes all morphisms between objects
of S''
>
> > For example, this (line 1236) is mathematically false:
> > {{{
> > sage: Algebras(QQ).FiniteDimensional().is_subcategory(
Modules(QQ).FiniteDimensional() )
> > True
> > }}}
>
> According to the above definitions, this is definitely not a full
> subcategory, but it is a subcategory.
It is not, for the same reason that graded algebras don't form a
subcategory of graded modules.
(By the way, if you don't require algebras to have a unity, then graded
modules can be regarded as a subcategory of graded algebras! Just consider
every graded module as a graded algebra with multiplication being
identically 0. And this is in fact a full subcategory, because any
morphism of graded modules preserves this stupid multiplication.)
> > The claim that all subcategories are automatically full (line 1100) is
also mistaken; if it is supposed to mean that Sage only knows how to deal
with full subcategories (i.e., if I define a subcategory, then Sage will
automatically regard any morphism of the big category as a morphism of the
small one), then again THIS SHOULD BE DOCUMENTED.
>
> The claim on line 1100 is only about subcategories defined by an
> axiom. Those are full subcategories.
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.
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?
> > - Curious question: Is there any connection between the
AdditiveAssociative and Associative axioms? I.e., does the former profit
from methods bound to the latter in any way? Whether yes or not, this
might use a brief mention in the doc.
>
> No, alas no. The hierarchies for additive XXX and for multiplicative
> XXX are completely independent of each other. That's very annoying,
> because this means everything is duplicated.
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.
> What's really important is that you provide at least all the immediate
> super categories, which already requires some care when inserting new
> categories.
>
> Now, I agree with you that it would be better if the system did not
> mind if there occasionally were non immediate super categories
> too. This actually probably is already the case, but I would want to
> triple check the code before I relax this specification. In fact, we
> already are already massaging the super_categories by sorting them; it
> could make sense to remove duplicates at the same occasion, but I am
> not sure about the overhead. Since this specification precedes this
> ticket, that's anyway for latter.
Hmm. Should I open a new ticket for this?
> Together with the documentation of `Category`, I believe yes! But
> please make up your own mind.
Nice! (I probably can't make up my own mind about this, since reading the
whole source is over my head.)
Best regards,
Darij
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:572>
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.
