#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 | 8bbbfe7dc8e5e9c4fbba758424208e35070272c4
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by 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...
Some questions that I asked myself while reading the new categories primer
and couldn't answer (some of them rhetorical, sorry):
- 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?
- 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?
- 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``?
- 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
}}}
- 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, and an annoyance of mixins is that they don't
have documentation.
- The notions of "subcategory" and "full subcategory" used in the primer
(and probably in the rest of the doc?) conflict with mathematics. For
example, this (line 1236) is mathematically false:
{{{
sage: Algebras(QQ).FiniteDimensional().is_subcategory(
Modules(QQ).FiniteDimensional() )
True
}}}
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. 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.
- 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.
- 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.
- 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.
Please don't get me wrong -- 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...
Thanks a lot!
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:564>
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.
