#10668: Refactor category support for morphisms (Hom is not a functorial
construction!)
--------------------------+-------------------------------------------------
Reporter: nthiery | Owner: nthiery
Type: defect | Status: new
Priority: major | Milestone:
Component: categories | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
--------------------------+-------------------------------------------------
Comment(by nthiery):
Hi Simon!
I finally got to work on this. See:
http://combinat.sagemath.org/patches/file/tip/category-hom_methods-
nt.patch
It's just a proof of concept. The core of the patch implementing the
infrastructure is about 10 lines of code. The rest is (partially)
adapting the category code to make use of that infrastructure. I
haven't run all tests, and there are a couple things failing here and
there, but it should be about correct. At least the tests of
modules_with_basis basically pass :-)
= About attributes for specifying homset structures / full sub categories
=
I much prefer to use methods instead:
- This is consistent with what has been done so far (with
the method super_categories, ...)
- It is easier for a subclass to override
- It's only a tiny bit more verbose, since anyway one should write a
doctest for it, and since most categories do not have an __init__.
= About full subcategories =
I totally agree that we want this concept. I am not sure yet about the
syntax though. In the draft, I have implemented a separate method
"full_super_categories". However most of the time, this is quite
redundant with the super_categories method. So I'd rather have instead
the method super_categories include the information in its result. An
option would be to use something like:
def super_categories(self):
return [ (Semigroups(), "full"), Monoids() ]
Then full_super_categories and all_super_categories, ... would extract
the relevant information from the above.
We could be more fancy to avoid breaking backward compatibility:
def super_categories(self):
return annotated_list( [ (Semigroups(), "full"), Monoids() ])
where annotated_list would be a helper class whose instances would
behave like usual lists, except that one could query annotations on
their elements, as in:
"full" in l.annotations(Semigroups())
= Things that still need discussion =
- Do we want all morphisms, and in particular SetMorphism's to
systematically inherit from categories (that wasn't the case yet)
- How should categories specify the class to use for their homsets?
This currently is done in a couple spots by having
C.HomCategory.ParentMethods inherit from some specific homset. But
that's quite hugly (ParentMethods is supposed to be an abstract
class with just generic methods). Or maybe, that won't be needed
anymore once things will be cleaned up: there will be a single
concrete Homset class, and all the rest will be provided by the
categories?
- Where should the constructors for the various types of morphisms be
stored? In C.MorphismMethods? In C.ParentMethods (like is currently
done with module_morphism)? Elsewhere?
- super_categories and friends should probably return tuples instead
of lists. That's safer, especially since their results are cached.
- We probably want to move HomCategory in its own file
- Do we want to keep C.hom_category() or use C.Homsets() instead, for
consistency with C.CartesianProducts() and such.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10668#comment:16>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
