#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 nthiery):
Replying to [comment:564 darij]:
> I am *not* reviewing this ticket (not enough skill), but I am trying to
read up on the new features in the documentation. All commits I'm pushing,
unless declared otherwise, fix minor issues I find with the latter. Please
doublecheck them, because once again I am not exactly very competent at
this...
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!
> - 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.
> - 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__`.
> - This is not about something in the primer, but it's a question that
has been preying on my mind for a while. When implementing a parent method
like `product(self, a, b)` to multiply two elements `a` and `b`, can
(should?) I WLOG assume that `a` and `b` are already in the parent `self`,
or should I first cast them into `self`?
It's appropriate to check that they are indeed in `self`, typically
using `self.is_parent_of(a)`, and raise a value error otherwise.
> - 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!
> - 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!
> and an annoyance of mixins is that they don't have documentation.
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.
> - 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''
``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.
> 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.
> - 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.
I know of no computer algebra system that has a good solution for
this, and any great idea to tackle this is more than welcome.
I am not sure how to phrase this in the primer, but feel free to
introduce some lines on the topic wherever you may see fit.
> - Line 1377 of the primer:
> {{{
> ``C.super_categories()`` *must* return a list of categories, namely
> the *immediate* super categories of `C`.
> }}}
> Does this mean that it is FORBIDDEN to provide non-immediate
supercategories (i.e., categories with some supercategories inbetween)?
This is somewhat important because if true, it means that one has to be
particularly careful when introducing new categories into the graph, and
remove all redundant paths when doing so. Again, something that the reader
should be warned about. But I'm hoping that this is not the case, as I
don't see a reason why this should be required.
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.
Now if you believe the above comment is important to mention, feel
free to add a note right now.
> - Do the primer, along with the module-wide doc of
`category_with_axiom.py`, document everything one needs to know when
introducing new categories into the framework? I'm planning to read the
latter in foreseeable time.
Together with the documentation of `Category`, I believe yes! But
please make up your own mind. And feel free to add a word in the
primer about this.
> Please don't get me wrong
I am not. This is super constructive!
> most of the primer is very readable and indeed quite fun to
> read. I'd in fact be happy if all of Sage's documentation was like
> that...
:-)
Cheers,
Nicolas
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=4cd76af11b574392811ab52237e83ddb5fc5d424
4cd76af]||{{{repeat some #8389 edits to make a cleaner merge with
6.2.beta4}}}||
||[http://git.sagemath.org/sage.git/commit/?id=777ea6587cfce214f466f433f66b98acf22553cb
777ea65]||{{{manual merge}}}||
||[http://git.sagemath.org/sage.git/commit/?id=5422cbc169f4cbc94fddeb3d00bea351536a36db
5422cbc]||{{{localize imports}}}||
||[http://git.sagemath.org/sage.git/commit/?id=1cdc128a85851dd007b3b77ec53a4853a10e1de4
1cdc128]||{{{I can't count}}}||
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=4cd76af11b574392811ab52237e83ddb5fc5d424
4cd76af]||{{{repeat some #8389 edits to make a cleaner merge with
6.2.beta4}}}||
||[http://git.sagemath.org/sage.git/commit/?id=777ea6587cfce214f466f433f66b98acf22553cb
777ea65]||{{{manual merge}}}||
||[http://git.sagemath.org/sage.git/commit/?id=5422cbc169f4cbc94fddeb3d00bea351536a36db
5422cbc]||{{{localize imports}}}||
||[http://git.sagemath.org/sage.git/commit/?id=1cdc128a85851dd007b3b77ec53a4853a10e1de4
1cdc128]||{{{I can't count}}}||
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:569>
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.
