Refactor category support for morphisms (Hom is not a functorial construction!)

[nthiery]

Before this ticket, Hom was implemented as a covariant functorial construction:

    sage: Rings().hom_category()
    Category of hom sets in Category of rings
    sage: Rings().hom_category().super_categories()
    [Category of hom sets in Category of sets]

The intention was to model the fact that a morphism in a category is also a morphism in any super category, via the forgetful functor. With the example above, if A and B are rings, then a ring morphism phi: A->B is also a set morphism. However, at the level of parents, and as noted in the documentation of sage.category.HomCategory?, this is mathematically plain wrong: if A and B are rings, then Hom(A,B) in the category of rings does not coincide with Hom(A,B) in the category of sets.

I, Nicolas, take full blame for this misfeature; it was just the shortest route to implement some urgently needed features about morphisms, and still get that huge chunk of category code done.

Status of the current reimplementation:

• Add support for a MorphismsMethods? subclass, similar to ElementMethods? and ParentMethods?. If Cat is a category, then Cat.MorphismMethods? will provide generic methods for morphisms in Cat and in any subcategory. This can be achieved by:

• Building of a hierarchy of abstract classes Cat.morphism_class, similar to Cat.element_class and Cat.parent_class (10 lines of code; see Category.element_class).

• Having morphisms in Cat inherit from Cat.morphism_class; this is implemented by overriding Parent.morphism_class. An alternative would have been to override Category.element_class in HomsetsCategory.element_class.

• Rename both HomCategory? and hom_category to Homsets, for consistency with the other constructions like CartesianProducts?, ...

• Fix HomCategory?: for Cat a category, the purpose of Cat.hom_category() shall be to provide mathematical information about its homsets (e.g. that a homset in the category of vector spaces is also a vector space). It is only a subcategory of the homsets of the full super categories of Cat (a homset in the category of finite groups is also a homset in the category of groups).

• Remove HomCategory? from the global namespace.

Potential further desirable features for a later ticket:

• If CatA is a subcategory of CatB, add automatic coercion (or just conversion?) from Hom(A,B, CatA) to Hom(A, B, CatB), modeling the appropriate forgetful functor. There are too many such coercions for them to be registered explicitly. So this probably needs to be implemented through a specific CatB._has_coerce_map_from(A) for homsets.

• Extend/use sage.categories.pushout to handle mixed morphism arithmetic (e.g. having the sum of an algebra morphism and a coalgebra morphism return a vector space morphism).

[SimonKing]

Replying to nthiery:

The intention was to model the fact that a morphism in a category is also a morphism in any super category, via the forgetful functor. With the example above, if A and B are rings, then a ring morphism phi: A->B is also a set morphism. However, at the level of parents, and as noted in the documentation of sage.category.HomCategory?, this is mathematically plain wrong: if A and B are rings, then Hom(A,B) in the category of rings does not coincide with Hom(A,B) in the category of sets.

I don't see why this should be wrong: Any ring homomorphism is a set homomorphism. Hence, Hom_Rings()(A,B) is a subset of Hom_Sets()(A,B) -- nobody claims that they coincide.

Here are some thoughts for a proper implementation:

• Add support for a HomMethods? subclass, similar to ElementMethods? and ParentMethods?. If Cat is a category, then Cat.ElementMethods? will provide generic methods for morphisms in Cat and any subcategory.

You mean "Cat.HomMethods? will provide...", I guess.

• Reimplement HomCategory?. For Cat a category, the purpose of Cat.hom_category() shall be to provide mathematical information about its homsets (e.g. that a homset in the category of vector spaces is also a vector space). It should ignore the super categories of C in general, except if is a full subcategory (a homset in the category of finite groups is also a homset in the category of groups).

The approach with HomMethods would provide methods defined for homsets, whereas the fact that a homset of vector spaces is a vector space has implications for the methods of elements of the homsets (i.e., for methods of morphisms).

I don't know whether we need special methods for homset, but of course it would be nice to have homsets that are vector spaces.

What about the following approach:

• There is the base class sage.categories.category.HomCategory. I suggest to provide it with an optional argument hom_structure. Define, for example, H = HomCategory(Algebras(QQ),hom_structure=VectorSpaces(QQ)). Then, H is the category of homsets in the category of algebras over QQ, and each homset would automatically be a vector space over QQ. Moreover, H would be a sub-category of VectorSpaces(QQ).

• I suggest to introduce a lazy attribute C.hom_structure, that defaults to C.HomStructure if that exists, and otherwise returns the join of S.hom_structure for all S in C.super_categories(). Then, C.hom_category() defaults to HomCategory(C, hom_structure=C.hom_structure).

• Of course, any category can define a custom HomStructure (e.g., in the __init__ method of VectorSpaces(R), we would define self.HomStructure=self, ensuring that self.hom_structure is the right thing). In order to avoid an infinite recursion of the lazy attribute, we also need to define Objects().HomStructure=Objects().

• If CatA is a subcategory of catB, add automatic coercion (or just conversion?) from Hom(A,B, CatA) to Hom(A, B, CatB), modeling the appropriate forgetful functor. There are too many such coercions for them to be registered explicitly. So this probably need to be implemented through a specific CatB._has_coerce_map_from(A) for homsets.

That would be a good candidate for your HomMethods, don't you think?

Some extra work will probably be needed if one wants to handle mixed morphism arithmetic (e.g. having the sum of an algebra morphism and a coalgebra morphism return a vector space morphism).

I guess that would be an extension of the sage.categories.pushout formalism.

Anyway, my suggestion is to start with the hom_structure approach, as it seems to be relatively straight forward to implement.

[nthiery]

Replying to SimonKing:

Replying to nthiery:

The intention was to model the fact that a morphism in a category is also a morphism in any super category, via the forgetful functor. With the example above, if A and B are rings, then a ring morphism phi: A->B is also a set morphism. However, at the level of parents, and as noted in the documentation of sage.category.HomCategory?, this is mathematically plain wrong: if A and B are rings, then Hom(A,B) in the category of rings does not coincide with Hom(A,B) in the category of sets.

I don't see why this should be wrong: Any ring homomorphism is a set homomorphism. Hence, Hom_Rings()(A,B) is a subset of Hom_Sets()(A,B) -- nobody claims that they coincide.

Very short answer for now: here the question is whether Hom_Rings()(A,B) is an object of Hom_Sets(). It's not. The point of VectorSpaces?().HomCategory?() is to encode mathematical information about the homsets, like the fact that Hom(A,B) is itself a vector space. We don't want this information to be applied to a homset of a subcategory (a homset in Algebras() being certainly not a vector space).

[SimonKing]

Replying to nthiery:

Very short answer for now: here the question is whether Hom_Rings()(A,B) is an object of Hom_Sets(). It's not. The point of VectorSpaces?().HomCategory?() is to encode mathematical information about the homsets, like the fact that Hom(A,B) is itself a vector space. We don't want this information to be applied to a homset of a subcategory (a homset in Algebras() being certainly not a vector space).

Right.

Nevertheless, I believe that an attribute like C.hom_structure would be a convenient way to declare that the homsets of C all have a particular structure (like Rings() or VectorSpaces(C.base_ring())) and that therefore C.hom_category() is a sub-category of C.hom_structure.

So, for now, the only detail that I have to withdraw from my proposal is that C.hom_structure will not be influenced by X.hom_structure for a super-category X of C.

[nthiery]

Replying to nthiery:

More later when I'll have recharged my battery ...

[SimonKing]

Replying to nthiery:

• Add support for a MorphismsMethods? subclass, similar to ElementMethods? and ParentMethods?. If Cat is a category, then Cat.MorphismMethods? will provide generic methods for morphisms in Cat and in any subcategory.

Not in a sub-category! Namely, if Cat is the category of F-vectorspaces, then Cat.MorphismMethods would include addition and skalar multiplication. But for a sub-category of Cat, such as F-algebras, we don't want that, as you had pointed out.

This can be achieved by:

• Building of a hierarchy of abstract classes Cat.morphism_class, similar to Cat.element_class and Cat.parent_class (10 lines of code; see Category.element_class).

I don't see such hierarchy.

• Having morphisms in Cat inherit from Cat.morphism_class.

I really think the Cat.hom_structure formalism that I suggested would be easier.

Any category would provide its own hom-structure (and there would be no inheritance for sub-categories), of course Objects() being the default hom-structure.

Then, homsets in Cat would inherit from Cat.hom_structure.parent_class, whereas morphisms in Cat would inherit from Cat.hom_structure.element_class.

In particular, there is no need to provide Cat.HomMethods or Cat.MorphismMethods. In fact, they are redundant: If you simply state that Cat.hom_structure is VectorSpaces(QQ), then the morphisms already have the element methods of vector spaces, whereas in your approach you needed to restate (copy-and-paste) them as Cat.MorphismMethods.

[nthiery]

Replying to SimonKing:

Not in a sub-category! Namely, if Cat is the category of F-vectorspaces, then Cat.MorphismMethods would include addition and skalar multiplication. But for a sub-category of Cat, such as F-algebras, we don't want that, as you had pointed out.

Of course addition should not be put in MorphismMethods?. On the other hand, there are a lot of generic operations on morphisms that pass down to subcategories, like inverting a morphism (say in the category of finite sets) or computing the matrix/the rank/the det/you_name_it of a morphism of finite dimensional vector space. It is essential to pass those generic methods down to subcategories.

That is not a vague though that popped up when I created this ticket, but a concrete feature that we have been longing for years and we could not implement in MuPAD (MuPAD categories did not handle morphisms) despite our many use cases.

I really think the Cat.hom_structure formalism that I suggested would be easier.

And I think mine is no more complicated, while being more consistent with the rest of the framework :-)

It seems like most of the discussion comes from confusion and vagueness (and I take my share of the blame for that). So let's both write a little prototype to have a concrete ground to discuss on. We don't have to include the coercion / push_out part in this prototype since we agree on it. I can try to implement mine sometime next week.

In particular, there is no need to provide Cat.HomMethods or Cat.MorphismMethods. In fact, they are redundant: If you simply state that Cat.hom_structure is VectorSpaces(QQ), then the morphisms already have the element methods of vector spaces, whereas in your approach you needed to restate (copy-and-paste) them as Cat.MorphismMethods.

Cat.HomCategory?() will still use the standard super_categories() approach to state that it is a subcategory of VectorSpaces?(), and its elements will inherit from VectorSpaces?().element_class.

Cheers,

Nicolas

PS: by the way, I am wondering if we should be using Cat.objects() or Cat.Objects() (given that we already have Cat.Quotients(), Cat.Subobjects(), Cat.CartesianProducts?(), ...). Here, I am thinking about using the occasion to replace Cat.hom_category() by Cat.Homsets().

[SimonKing]

Replying to nthiery:

Replying to SimonKing:

Not in a sub-category! Namely, if Cat is the category of F-vectorspaces, then Cat.MorphismMethods would include addition and skalar multiplication. But for a sub-category of Cat, such as F-algebras, we don't want that, as you had pointed out.

Of course addition should not be put in MorphismMethods?. On the other hand, there are a lot of generic operations on morphisms that pass down to subcategories, like inverting a morphism (say in the category of finite sets) or computing the matrix/the rank/the det/you_name_it of a morphism of finite dimensional vector space. It is essential to pass those generic methods down to subcategories.

I see. Yes, for those kind of methods, your approach makes very much sense.

But what would actually prevent us from doing both? Our two approaches are good for different things, and they are orthogonal to each other. If I understand correctly, you suggest that there should be Cat.morphism_class from which morphisms inherit, analogous to Cat.element_class, thereby getting "hereditary" (to sub-categories) methods. I suggest that Cat should have an attribute that allows Cat.hom_category() to assign the correct category to the homset category (hence, Cat.hom_category().is_subcategory(Cat.hom_structure)), so that homomorphism would inherit from Cat.hom_structure.element_class (by the existing framework - hence, my suggestion is indeed very consistent with with the existing framework :-).

Is there any reason to not have a double inheritance from Cat.morphism_class and Cat.hom_structure.element_class (Cat.hom_structure being a category)?

So let's both write a little prototype to have a concrete ground to discuss on. We don't have to include the coercion / push_out part in this prototype since we agree on it. I can try to implement mine sometime next week.

OK.

Cat.HomCategory?() will still use the standard super_categories() approach to state that it is a subcategory of VectorSpaces?(), and its elements will inherit from VectorSpaces?().element_class.

OK, this is what I suggested above: One needs to introduce a standard mechanism to declare the category which Cat.hom_category() is sub-category of.

[nthiery]

But what would actually prevent us from doing both?

Ah, good, we now fund the point were we did not understand each other. The plan is definitely to do both! That is have inheritance from Cat.morphism_class and Cat.hom_category().element_class.

OK, this is what I suggested above: One needs to introduce a standard mechanism to declare the category which Cat.hom_category() is sub-category of.

And that's a second misunderstanding: this mechanism already exists, and I am not planning to remove it (though the syntax might change a tiny bit; we probably don't need the extra_super_categories thingy, and just use super_categories.

What do you think of using the occasion to rename Cat.hom_category() into Cat.Homsets(), for consistency with Cat.Quotients() and the like?

Cheers,

Nicolas

[SimonKing]

Replying to nthiery:

OK, this is what I suggested above: One needs to introduce a standard mechanism to declare the category which Cat.hom_category() is sub-category of.

And that's a second misunderstanding: this mechanism already exists, and I am not planning to remove it (though the syntax might change a tiny bit; we probably don't need the extra_super_categories thingy, and just use super_categories.

What mechanism do you mean? I am of course aware of the extra_super_category method - but sage.categories.category.HomCategory.extra_super_category() returns [], and sage.categories.category.HomCategory.super_categories() returns stuff that we don't want (namely C.hom_category() for all C in self.base_category.super_categories()).

Of course, it would suffice to make VectorSpaces(QQ).hom_category().extra_super_categories() return [VectorSpaces(QQ)]. But this would currently require to introduce a custom HomCategory class for VectorSpaces that overrides the method of the HomCategory base class. This is not nice and should be simplified.

What I plan is: Remove inheritance of the hom-categories of the super-categories of the base-category from sage.categories.category.HomCategory.super_categories(); it should basically return self.extra_super_categories()+[Sets()]. Moreover, define sage.categories.category.HomCategory.extra_super_categories() like this:

def extra_super_categories(self):
    try:
        return [self.base_category.hom_structure]
    except AttributeError:
        return []

Then, in the init-method of the category of vector spaces, one would simply add the line

        self.hom_structure = self

Similarly (I hope that I am not confusing things now), one would add the line

        self.hom_structure = LeftModules(self.base_ring())

to the init method of right modules; and self.hom_structure = RightModules(self.base_ring()) for left modules, and so on. That seems easier than defining a whole class HomCategory for LeftModules.

What do you think of using the occasion to rename Cat.hom_category() into Cat.Homsets(), for consistency with Cat.Quotients() and the like?

Personally, I don't like uppercase method names, and I remember that it is officially recommended to avoid capital letters in Python method or function or module names, whereas upper case is recommended to use for classes (but I do not remember where I was reading that recommendation).

Best regards,

Simon

[SimonKing]

A technical question:

For things to work, it is needed that Fields().hom_category().parent_class inherits from Rings().hom_category().parent_class.

I thought that the inheritance would be provided by the category framework, if we have Fields().hom_category().is_subcategory(Rings().hom_category()) (which, I guess, is mathematically correct). Unfortunately, even though I arranged things so that indeed Fields().hom_category().is_subcategory(Rings().hom_category()), I still get no inheritance of the parent classes.

So, how can one inherit the parent class of a super-category?

[SimonKing]

Replying to SimonKing:

A technical question:

For things to work, it is needed that Fields().hom_category().parent_class inherits from Rings().hom_category().parent_class.

Sorry for asking: It seems to work. I misinterpreted an error message.

[SimonKing]

I wonder whether it wouldn't be better to build upon #10667. There, amongst other things, I try to separate CategoryObject from SageObject and remove some inappropriate category stuff from elements and morphisms. I think that this part of #10667 could help me to implement my approach.

I suggest that I prepare my patch on top of #10667; you can of course do differently with the implementation of your approach.

[nthiery]

Replying to SimonKing:

I wonder whether it wouldn't be better to build upon #10667. There, amongst other things, I try to separate CategoryObject from SageObject and remove some inappropriate category stuff from elements and morphisms. I think that this part of #10667 could help me to implement my approach.

I suggest that I prepare my patch on top of #10667; you can of course do differently with the implementation of your approach.

Sure, please take the easiest route for you! #10667 is already large enough, and I see the point of not introducing yet another dependency :-)

Cheers,

[SimonKing]

I just uploaded a preliminary patch, implementing my approach. The patch isn't finished (lacking doc tests), but is ready for discussion. It depends on #10667 (though it might apply with some noise without #10667 - test, if you like).

Features:

Structure of hom sets

As I announced, I introduced an attribute for categories C that determines a category which C.hom_category() is sub-category of. I call this attribute C.hom_structure:

# This was already fixed by #10667
sage: LeftModules(ZZ).hom_category()
Category of hom sets in Category of left modules over Integer Ring
sage: type(LeftModules(ZZ).hom_category())
<class 'sage.categories.sets_cat.Sets.HomCategory'>
# This is new:
sage: LeftModules(ZZ).hom_category().is_subcategory(RightModules(ZZ))
True
sage: issubclass(LeftModules(ZZ).hom_category().parent_class, RightModules(ZZ).parent_class)
True
# Reason for it working:
sage: LeftModules(ZZ).hom_structure
Category of right modules over Integer Ring

The attribute C.hom_structure is used in sage.categories.HomCategory.extra_super_categories().

Hierarchy of hom-categories

Recall that currently, the hierarchy of hom-categories goes parallel with the hierarchy of their base categories, which is wrong.

However, if C1 is a full sub-category of C2 then (and only then) we should indeed have C1.hom_category().is_subcategory(C2.hom_category()). Similar to the method C.super_categories(), I introduce an attribute C.full_subcategory_of, that provides a list of immediate super categories in which C is full.

With that, I have:

sage: IntegralDomains().full_subcategory_of
[Category of commutative rings, Category of domains]
sage: Domains().full_subcategory_of
[Category of rings]
sage: IntegralDomains().hom_category().is_subcategory(CommutativeRings().hom_category())
True
sage: IntegralDomains().hom_category().is_subcategory(Rings().hom_category())
True

and, in particular

sage: issubclass(IntegralDomains().hom_category().parent_class, Rings().hom_category().parent_class)
True

Self-criticism

It is not very pythonic to do those things with an attribute - usually, methods are better. However, an attribute is easier to add, and it is faster to access.

I am not sure whether I got the "full subcategory" business right in all cases.

[SimonKing]

Category support for hom categories - depends on #10667

[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

[nthiery]

Replying to 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

[nthiery]

Some food for thought (taken from Rings.HomCategory? before #12876):

When X is a quotient field, we can build a morphism from X to Y by specifying the images of the generators. This is not something about the category, because Y need not be a quotient field.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​e87c4dd	10668: specify that NN is commutative
​5ea3234	10668: CategoryWithAxiom: simplified _without_axioms logic and improved repr
​59fa15e	10668: Removed unused import
​18b3483	10668: Implement EndSets; construct the abstract element class in the homset not the homset category
​06db0c5	10668: Trivial comment addition in Sets.ElementMethods
​4d4b599	10668: Fixed refinement of category to handle Parent._abstract_element_class
​125aa8e	10668: Simplify the logic of endsets of modular abelian varieties using the new Endsets construction
​fc5b0f1	10668: trivial doctest output updates w.r.t. the new printing of homsets
​4b67d7c	10668: Explicitly document that Element.__getattr__ can also be useful when refining categories
​ad87027	10668: Fixed doctest

[nthiery]

For the record: all long tests passed.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​9051050

10668: fixed ReST typo

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​ac38eda

10668: trivial ReST fix

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​eaa56bc	16340: super_structure_categories -> all_structure_super_categories
​afc9724	Merge branch 'develop' into categories/full-subcategories-16340
​21bf60a	Merge branch 'categories/full-subcategories-16340' and '6.3beta5' into categories/morphism-methods-10668
​9de8909	10668: super_structure_categories -> all_structure_super_categories

[nthiery]

For the record: all long tests passed for me, and the pdf documentation compiles.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​93273a7	Merge branch 'u/nthiery/categories/full-subcategories-16340' of trac.sagemath.org:sage into public/categories/full_subcategories-16340
​edb29e6	Fixed trivial doctest failures.
​99a8eb1	Merge branch 'public/categories/full_subcategories-16340' of trac.sagemath.org:sage into categories/full-subcategories-16340
​8bc456c	Merge branch 'master=6.3' into categories/full-subcategories-16340
​56e982e	Merge branch 'categories/full-subcategories-16340' and 6.3 into categories/morphism-methods-10668

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​016cd16

#16340: Revert ReST typo fix in ell_curve_isogeny.py to avoid conflict with other ticket handling it

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d147678

Merge branch 'develop=6.4.beta0' into categories/morphism-methods-10668

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​33463c4

10668: rebase doctest upon the fact that Monoids.Commutative now exists

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​dc0d1db	8678: removed explicit doctest:xxx: source line number from a doctest
​8457690	8678: trivial doctest update after merge with develop
​62a28dd	8678: rewrote a few tests introduced by #16296 so that they do not depend on the number of axioms defined in Sage

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​2b3ee81

Merge branch 'develop = 6.4 beta2' into categories/morphism-methods-10668

[SimonKing]

Work plan: Review this after #16340.

[SimonKing]

Nicolas asked me to look at this here first, since he is now working on #16340.

[git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

​1e4418f	Merge branch 'develop' into categories/full-subcategories-16340
​e5f210c	Merge branch 'public/categories/full_subcategories-16340' of trac.sagemath.org:sage into public/categories/full_subcategories-16340
​d4c7a88	Specified more categories as not being structure categories.
​708cc41	Merge branch 'public/categories/full_subcategories-16340' of trac.sagemath.org:sage into categories/full-subcategories-16340
​29a6c67	16340: reverted change to CoxeterGroups.is_structure_category() + explanations in the doc
​60aa128	16340: fixed typos
​950b039	16340: Merge branch 'develop = 6.4 beta4' into categories/full-subcategories-16340
​b14ca6c	16340: revert change, and add documentation thereabout: the category of permutation groups defines additional structure
​43b25d4	16340: is_structure_category -> additional_structure, all_super_structure_categories -> structure, default for functorial construction categories
​54fe992	10668: merged in latest 16340 (and develop=6.4 beta4)

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​9398475

10668: fixed the endset logic, and updated (all?) doctests accordingly

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​75615b5

10668: trivial doctest updates

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d5d3a97

10668: improved description of the HomsetsOf class

[SimonKing]

For the record: I opened #17150, to make the conversion/coercion/call mechanism of homsets closer to what we do for other parents.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​5416ba0

Add a note on the MRO used for Homset._abstract_element_class

[SimonKing]

TODO:

Add documentation to the category_of method, which seems to return an instance of HomsetsOf. It is absolutely unclear to me what it is supposed to be or to do.

[SimonKing]

I wonder about Homsets.Endset.super_categories, which returns [Monoids()]. Shouldn't this rather be extra super categories? If not, why not?

[SimonKing]

TODO:

We have

sage: Posets().Homsets().Endset().super_categories()
[Category of homsets, Category of homsets of posets]

hence, in spite of Homsets.Endset.super_categories, the fact that endsets are monoids is not mentioned.

[SimonKing]

Why am I logged out of trac after few seconds? This has happened at least 10 times this evening.

Anyway.

What is the point of Modules.EndCategory? Shouldn't it be implemented as an axiom Endset, by the framework provided in this ticket?

[SimonKing]

The good news: All doctests pass. But I think it needs work, to address the concerns expressed in my previous comments.

[SimonKing]

Replying to SimonKing:

TODO:

We have

sage: Posets().Homsets().Endset().super_categories()
[Category of homsets, Category of homsets of posets]

hence, in spite of Homsets.Endset.super_categories, the fact that endsets are monoids is not mentioned.

Changing Homsets.Endset.super_categories into extra_supercategories does not help. Nicolas, do you know how to fix that?

[SimonKing]

Replying to SimonKing:

The good news: All doctests pass. But I think it needs work, to address the concerns expressed in my previous comments.

Oops, I made a wrong test. When using extra_supercategories, the following does give the correct result:

sage: Posets().Homsets().Endset().is_subcategory(Monoids())
True

[nthiery]

Replying to SimonKing:

Replying to SimonKing:

We have

sage: Posets().Homsets().Endset().super_categories()
[Category of homsets, Category of homsets of posets]

hence, in spite of Homsets.Endset.super_categories, the fact that endsets are monoids is not mentioned.

The source of confusion is that the first entry above should have read as "Category of endsets". I just fixed that (a trivial thing in _repr_) and will push shortly.

Now I have::

sage: Posets().Endsets().super_categories()
[Category of endsets, Category of homsets of posets]

An it's normal that monoids don't show up above because they are a super category of the category of endsets. Just as a double check:

sage: Posets().Endsets().is_subcategory(Monoids())
True
sage: Posets().Homsets().Endset().is_subcategory(Monoids())
True

Cheers,

Nicolas

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​23639a9

Fix more typos

[SimonKing]

Replying to nthiery:

The source of confusion is that the first entry above should have read as "Category of endsets". I just fixed that (a trivial thing in _repr_) and will push shortly.

Good. Please also add a test to the super_categories method. I have just push some typo fixes.

[SimonKing]

Now I went through the whole diff. The only remaining issues are "Add documentation to the category_of method" and the _repr_ problem you are working at now.

So, time for me to call it a day :-)

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​02a6a8a	10668: fixed representation of the category of endsets
​477d381	10668: Homsets.Endset.super_category -> extra_super_category + documentation
​877bfdb	10668: fix: Modules.EndCategory -> Modules.Homsets.Endset + made it functional: endsets of modules are algebras

[nthiery]

Replying to SimonKing:

What is the point of Modules.EndCategory? Shouldn't it be implemented as an axiom Endset, by the framework provided in this ticket?

Good catch; that piece had not been refactored. Now it even works :-)

[nthiery]

Replying to SimonKing:

Now I went through the whole diff. The only remaining issues are "Add documentation to the category_of method" and the _repr_ problem you are working at now.

The second piece is done now. I am about to work on the doc of category_of.

So, time for me to call it a day :-)

Yes indeed, thanks so much!

[nthiery]

Replying to SimonKing:

I wonder about Homsets.Endset.super_categories, which returns [Monoids()]. Shouldn't this rather be extra super categories? If not, why not?

Done.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​f86824e

10668: documentation for HomsetsCategory.category_of + fixed typo in doctest nearby

[nthiery]

I believe all discussion points have been addressed. Hence back to needs review.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​787f461

10668: proofreading of Homsets.category_of

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​a937938

Fixing two typos

[SimonKing]

All tests pass and all issues have been addressed. Hence, it's a positive review, of course modulo #16340.

[nthiery]

Thanks Simon :-) And thanks for coming over; that was a productive trip!