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).

Depends on #16340

CC: @sagetrac-sage-combinat @simon-king-jena

Component: categories

Author: Nicolas M. Thiéry

Branch: a937938

Reviewer: Simon King

Issue created by migration from https://trac.sagemath.org/ticket/10668

[simon-king-jena]

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]

comment:2

Replying to @simon-king-jena:

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).

[simon-king-jena]

comment:3

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]

comment:5

Replying to @nthiery:

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

[simon-king-jena]

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]

comment:7

Replying to @simon-king-jena:

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().

[simon-king-jena]

comment:8

Replying to @nthiery:

Replying to @simon-king-jena:

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]

comment:9

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

[simon-king-jena]

comment:10

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

[simon-king-jena]

comment:11

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?

[simon-king-jena]

comment:12

Replying to @simon-king-jena:

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.

[simon-king-jena]

comment:13

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]

comment:14

Replying to @simon-king-jena:

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,

[simon-king-jena]

comment:15

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.

[simon-king-jena]

Attachment: trac10668-category_support_for_homsets.patch.gz

Category support for hom categories - depends on #10667

[nthiery]

comment:16

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]

comment:17

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]

comment:18

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.

[nthiery]

Branch: u/nthiery/categories/morphism-methods-10668

[sagetrac-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

[sagetrac-git]

Commit: ad87027

[sagetrac-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]

comment:58

Replying to @simon-king-jena:

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]

comment:59

Replying to @simon-king-jena:

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]

comment:60

Replying to @simon-king-jena:

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

Done.

[sagetrac-git]

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

f86824e

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

[sagetrac-git]

Changed commit from 877bfdb to f86824e

[nthiery]

comment:62

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

[sagetrac-git]

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

787f461

10668: proofreading of Homsets.category_of

[sagetrac-git]

Changed commit from f86824e to 787f461

[sagetrac-git]

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

a937938

Fixing two typos

[sagetrac-git]

Changed commit from 787f461 to a937938

[simon-king-jena]

comment:65

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

[vbraun]

Changed branch from public/categories/morphism-methods-10668 to a937938

[nthiery]

Changed commit from a937938 to none

[nthiery]

comment:67

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