Opened 6 years ago

Closed 2 years ago

Last modified 2 years ago

#10668 closed defect (fixed)

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

Reported by: nthiery Owned by: nthiery
Priority: major Milestone: sage-6.4
Component: categories Keywords:
Cc: sage-combinat, SimonKing Merged in:
Authors: Nicolas M. Thiéry Reviewers: Simon King
Report Upstream: N/A Work issues:
Branch: a937938 (Commits) Commit:
Dependencies: #16340 Stopgaps:

Description (last modified by 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:

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

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

Attachments (1)

trac10668-category_support_for_homsets.patch (40.8 KB) - added by SimonKing 6 years ago.
Category support for hom categories - depends on #10667

Download all attachments as: .zip

Change History (68)

comment:1 in reply to: ↑ description ; follow-up: Changed 6 years ago by 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:

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.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 6 years ago by nthiery

  • Description modified (diff)

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

comment:3 in reply to: ↑ 2 Changed 6 years ago by 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.

comment:4 follow-up: Changed 6 years ago by nthiery

  • Description modified (diff)

comment:5 in reply to: ↑ 4 Changed 6 years ago by nthiery

Replying to nthiery:

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

comment:6 in reply to: ↑ description ; follow-up: Changed 6 years ago by SimonKing

Replying to nthiery:

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.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 6 years ago by 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().

comment:8 in reply to: ↑ 7 ; follow-up: Changed 6 years ago by 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.

comment:9 in reply to: ↑ 8 ; follow-up: Changed 6 years ago by 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

comment:10 in reply to: ↑ 9 Changed 6 years ago by 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

comment:11 follow-up: Changed 6 years ago by 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?

comment:12 in reply to: ↑ 11 Changed 6 years ago by 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.

comment:13 follow-up: Changed 6 years ago by 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.

comment:14 in reply to: ↑ 13 Changed 6 years ago by 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,

comment:15 Changed 6 years ago by 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.

Changed 6 years ago by SimonKing

Category support for hom categories - depends on #10667

comment:16 follow-up: Changed 6 years ago 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.
  • Do we want to keep C.hom_category() or use C.Homsets() instead, for consistency with C.CartesianProducts?() and such.

Cheers,

Nicolas

comment:17 in reply to: ↑ 16 Changed 5 years ago by 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.

+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

comment:18 Changed 5 years ago by 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.

comment:19 Changed 3 years ago by nthiery

  • Description modified (diff)

comment:20 Changed 3 years ago by nthiery

  • Branch set to u/nthiery/categories/morphism-methods-10668

comment:21 Changed 3 years ago by git

  • Commit set to ad87027e6ad2cabfc1bdaab2de061374403c9939

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

e87c4dd10668: specify that NN is commutative
5ea323410668: CategoryWithAxiom: simplified _without_axioms logic and improved repr
59fa15e10668: Removed unused import
18b348310668: Implement EndSets; construct the abstract element class in the homset not the homset category
06db0c510668: Trivial comment addition in Sets.ElementMethods
4d4b59910668: Fixed refinement of category to handle Parent._abstract_element_class
125aa8e10668: Simplify the logic of endsets of modular abelian varieties using the new Endsets construction
fc5b0f110668: trivial doctest output updates w.r.t. the new printing of homsets
4b67d7c10668: Explicitly document that Element.__getattr__ can also be useful when refining categories
ad8702710668: Fixed doctest

comment:22 Changed 3 years ago by nthiery

  • Description modified (diff)
  • Status changed from new to needs_review

comment:23 Changed 3 years ago by nthiery

For the record: all long tests passed.

comment:24 Changed 3 years ago by git

  • Commit changed from ad87027e6ad2cabfc1bdaab2de061374403c9939 to 90510508e41a09d90758f7c2e48071bebc8185d7

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

905105010668: fixed ReST typo

comment:25 Changed 3 years ago by nthiery

  • Authors set to Nicolas M. Thiéry
  • Dependencies set to 16340

comment:26 Changed 3 years ago by nthiery

  • Dependencies changed from 16340 to #16340

comment:27 Changed 3 years ago by git

  • Commit changed from 90510508e41a09d90758f7c2e48071bebc8185d7 to ac38edabd09cbe567e84866f269c6657f5c4fb02

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

ac38eda10668: trivial ReST fix

comment:28 Changed 3 years ago by git

  • Commit changed from ac38edabd09cbe567e84866f269c6657f5c4fb02 to 9de89090ec0c6072076caf5e248d4e6aa0613c7a

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

eaa56bc16340: super_structure_categories -> all_structure_super_categories
afc9724Merge branch 'develop' into categories/full-subcategories-16340
21bf60aMerge branch 'categories/full-subcategories-16340' and '6.3beta5' into categories/morphism-methods-10668
9de890910668: super_structure_categories -> all_structure_super_categories

comment:29 Changed 3 years ago by nthiery

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

comment:30 Changed 3 years ago by git

  • Commit changed from 9de89090ec0c6072076caf5e248d4e6aa0613c7a to 56e982e555deaf63ca1b064ca2685493f44db2af

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

93273a7Merge branch 'u/nthiery/categories/full-subcategories-16340' of trac.sagemath.org:sage into public/categories/full_subcategories-16340
edb29e6Fixed trivial doctest failures.
99a8eb1Merge branch 'public/categories/full_subcategories-16340' of trac.sagemath.org:sage into categories/full-subcategories-16340
8bc456cMerge branch 'master=6.3' into categories/full-subcategories-16340
56e982eMerge branch 'categories/full-subcategories-16340' and 6.3 into categories/morphism-methods-10668

comment:31 Changed 3 years ago by git

  • Commit changed from 56e982e555deaf63ca1b064ca2685493f44db2af to 016cd166f269f3cb21ef61a14a35f72d23d8f3a6

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

comment:32 Changed 3 years ago by git

  • Commit changed from 016cd166f269f3cb21ef61a14a35f72d23d8f3a6 to d147678711fc32df88a24e8c4ba16ad414179fee

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

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

comment:33 Changed 3 years ago by nthiery

  • Cc sage-combinat SimonKing added

comment:34 Changed 3 years ago by git

  • Commit changed from d147678711fc32df88a24e8c4ba16ad414179fee to 33463c4196d0906453cca976b94457b0fc353290

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

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

comment:35 Changed 3 years ago by git

  • Commit changed from 33463c4196d0906453cca976b94457b0fc353290 to 62a28dddc0d484aabcef16e914d873bbce6613ea

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

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

comment:36 Changed 3 years ago by git

  • Commit changed from 62a28dddc0d484aabcef16e914d873bbce6613ea to 2b3ee8104552292c87f0a19b6f787eb727210f96

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

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

comment:37 Changed 2 years ago by SimonKing

Work plan: Review this after #16340.

comment:38 Changed 2 years ago by SimonKing

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

comment:39 Changed 2 years ago by git

  • Commit changed from 2b3ee8104552292c87f0a19b6f787eb727210f96 to 54fe992bc3532106abcec15b1b32e514f8e7a459

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

1e4418fMerge branch 'develop' into categories/full-subcategories-16340
e5f210cMerge branch 'public/categories/full_subcategories-16340' of trac.sagemath.org:sage into public/categories/full_subcategories-16340
d4c7a88Specified more categories as not being structure categories.
708cc41Merge branch 'public/categories/full_subcategories-16340' of trac.sagemath.org:sage into categories/full-subcategories-16340
29a6c6716340: reverted change to CoxeterGroups.is_structure_category() + explanations in the doc
60aa12816340: fixed typos
950b03916340: Merge branch 'develop = 6.4 beta4' into categories/full-subcategories-16340
b14ca6c16340: revert change, and add documentation thereabout: the category of permutation groups defines additional structure
43b25d416340: is_structure_category -> additional_structure, all_super_structure_categories -> structure, default for functorial construction categories
54fe99210668: merged in latest 16340 (and develop=6.4 beta4)

comment:40 Changed 2 years ago by git

  • Commit changed from 54fe992bc3532106abcec15b1b32e514f8e7a459 to 9398475171db0afdfcedf3f8538eaaab058764a8

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

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

comment:41 Changed 2 years ago by SimonKing

  • Branch changed from u/nthiery/categories/morphism-methods-10668 to public/categories/morphism-methods-10668

comment:42 Changed 2 years ago by git

  • Commit changed from 9398475171db0afdfcedf3f8538eaaab058764a8 to 75615b5153afce1dc8a9e01d9db0ad4ccfe9de45

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

75615b510668: trivial doctest updates

comment:43 Changed 2 years ago by git

  • Commit changed from 75615b5153afce1dc8a9e01d9db0ad4ccfe9de45 to d5d3a97fcfbf3d2316d8096681c39da2996b8096

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

d5d3a9710668: improved description of the HomsetsOf class

comment:44 Changed 2 years ago by SimonKing

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

comment:45 Changed 2 years ago by git

  • Commit changed from d5d3a97fcfbf3d2316d8096681c39da2996b8096 to 5416ba0a866806b9746fd0e46c3888f2c308e73a

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

5416ba0Add a note on the MRO used for Homset._abstract_element_class

comment:46 Changed 2 years ago by 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.

comment:47 follow-up: Changed 2 years ago by SimonKing

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

comment:48 follow-up: Changed 2 years ago by 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.

comment:49 follow-up: Changed 2 years ago by 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?

comment:50 follow-up: Changed 2 years ago by SimonKing

  • Reviewers set to Simon King
  • Status changed from needs_review to needs_work

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

comment:51 in reply to: ↑ 48 ; follow-up: Changed 2 years ago by 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?

comment:52 in reply to: ↑ 50 Changed 2 years ago by 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

comment:53 in reply to: ↑ 51 ; follow-up: Changed 2 years ago by 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

comment:54 Changed 2 years ago by git

  • Commit changed from 5416ba0a866806b9746fd0e46c3888f2c308e73a to 23639a9288bdca85482a93ed029b3d1390309141

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

23639a9Fix more typos

comment:55 in reply to: ↑ 53 Changed 2 years ago by 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.

comment:56 follow-up: Changed 2 years ago by 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 :-)

comment:57 Changed 2 years ago by git

  • Commit changed from 23639a9288bdca85482a93ed029b3d1390309141 to 877bfdb215628b19c44a66d14ceee54824beaf14

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

02a6a8a10668: fixed representation of the category of endsets
477d38110668: Homsets.Endset.super_category -> extra_super_category + documentation
877bfdb10668: fix: Modules.EndCategory -> Modules.Homsets.Endset + made it functional: endsets of modules are algebras

comment:58 in reply to: ↑ 49 Changed 2 years ago by 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 :-)

comment:59 in reply to: ↑ 56 Changed 2 years ago by 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!

comment:60 in reply to: ↑ 47 Changed 2 years ago by 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.

comment:61 Changed 2 years ago by git

  • Commit changed from 877bfdb215628b19c44a66d14ceee54824beaf14 to f86824ea354a5260b2ee0b8f24f239c8b5178bdd

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

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

comment:62 Changed 2 years ago by nthiery

  • Milestone set to sage-6.4
  • Status changed from needs_work to needs_review

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

comment:63 Changed 2 years ago by git

  • Commit changed from f86824ea354a5260b2ee0b8f24f239c8b5178bdd to 787f461ff097e860f21ebf990f67e74185f84d53

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

787f46110668: proofreading of Homsets.category_of

comment:64 Changed 2 years ago by git

  • Commit changed from 787f461ff097e860f21ebf990f67e74185f84d53 to a9379383081f2ae7d42c0e17601c6e549269899c

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

a937938Fixing two typos

comment:65 Changed 2 years ago by SimonKing

  • Status changed from needs_review to positive_review

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

comment:66 Changed 2 years ago by vbraun

  • Branch changed from public/categories/morphism-methods-10668 to a9379383081f2ae7d42c0e17601c6e549269899c
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:67 Changed 2 years ago by nthiery

  • Commit a9379383081f2ae7d42c0e17601c6e549269899c deleted

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

Note: See TracTickets for help on using tickets.