#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:
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
--------------------------+-------------------------------------------------
Comment(by nthiery):
Replying to [comment:16 nthiery]:
Some notes after face to face discussion with Simon:
> - Do we want all morphisms, and in particular SetMorphism's to
> systematically inherit from categories (that wasn't the case yet)
Eventually yes.
> - 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?
Each category should have a `Homset` attribute specifying which
concrete class to use for its homset. The default value for that
attribute (implemented as a lazy attribute) is too pickup the first
non default Homset attribute in the list of full_super_categories(),
or sage.category.homset.Homset if there is none.
> - 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?
For `A` a parent, `A.hom(on_basis = [data],...)` would call
`A.morphism_on_basis(data,...)`. This `morphism_on_basis` could
typically be implemented in `A`, or in `C.ParentMethods` for `C` the
category of `A`.
There are 5-6 explicit hom functions in Sage that would need to be
generalized to accept this syntax, while keeping backward
compatibility if no keyword is specified.
> - super_categories and friends should probably return tuples instead
> of lists. That's safer, especially since their results are cached.
The new `_super_categories` lazy attribute should be a tuple. In the
long run, all_super_categories and friends would best return tuples
for safety (especially since they are cached). Probably
super_categories as well. It would be good to allow soon
super_categories to return a tuple. However this might induce speed
regression in the C3 implementation.
> - We probably want to move HomCategory in its own file
+1
> - Do we want to keep C.hom_category() or use C.Homsets() instead, for
> consistency with C.CartesianProducts() and such.
That would make sense. Comments anyone?
Little inconvenient: possible confusion between `C.Homset` (the
concrete class to be used for homsets in this category) and
`C.Homsets()` (the category of homsets in this category).
Simon and Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10668#comment:17>
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.
