Axioms for semigroups: L,R,J,H-trivial, aperiodic

[nthiery]

This ticket defines the usual Green axioms for semigroups, and provides stubs for the corresponding categories:

sage: Semigroups().LTrivial()
Category of ltrivial semigroups
sage: Semigroups().LTrivial().RTrivial()
Category of jtrivial semigroups
sage: Semigroups().HTrivial().Finite()
Category of finite aperiodic semigroups
sage: Semigroups().Commutative().RTrivial()
Category of commutative jtrivial semigroups

This is a first step toward #18001.

[nthiery]

New commits:

​2e678e6

18265: setup axioms for L,R,J,H trivial and aperiodic semigroups

[nthiery]

I am setting it to needs review to get the patchbot to pick it up.

[tscrim]

It would be good for the new files to have the standard copyright template: ​http://doc.sagemath.org/html/en/developer/coding_basics.html#headings-of-sage-library-code-files.

Patchbot report has also come in and states errors in

sage -t --long src/sage/categories/semigroups.py  # 5 doctests failed

along with docbuilding issues.

[git]

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

​f5185bc	Merge branch 'develop' into semigroups/axioms-18265
​ba12c41	18265: minor doc improvement, non verbose TestSuite, marked category example as not implemented (in this ticket)

[git]

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

​282be1f	18265: added reference to #20515 + some explanations
​01a9efe	18265: fixed the copyright headers of the new files
​2dc3f8a	18265: added the new categories to the reference manual

[git]

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

​77776ed	18265: fixed monoid to semigroup in several spots of the documentation
​18baeef	18265: uncapitalize module title

[git]

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

​61cf0f4

18265: fixed references to wikipedia

[git]

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

​7943a39

18265: proofread the html documentation

[nthiery]

Thanks Travis for having a look. The patchbot should go green now, and I have finished cleaning things up.

Up for review for real now!

[tscrim]

Some comments:

• Do we want these to be axioms since these properties for subcategories do not make as much sense (e.g., for groups, L-trivial = R-trivial = J-trivial = category consisting only of the trivial group, correct?)
• Typo "preoder".
• Do we want to spend some time trying to beautiful axiom printing (i.e., "J-trivial" instead of "jtrivial")?
• I would like to see the defining properties to the category level documentation, not only in the subcategory methods.

[git]

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

​d09fe3b

18265: typo: preoder -> preorder

[nthiery]

Hi Travis,

Thanks for the review.

Replying to tscrim:

• Do we want these to be axioms since these properties for subcategories do not make as much sense (e.g., for groups, L-trivial = R-trivial = J-trivial = category consisting only of the trivial group, correct?)

We want them to be axioms to interact nicely with each other: there will be many interesting combinations between the Finite / X-trivial / Unital axioms (and more will come, like Regular, ...). In fact implementing those was one of my original motivation for implementing axioms in Sage :-)

Indeed Groups().XTrivial() is, well, trivial, so that's boring. But this is only polluting the namespace of the Groups() category, not the groups themselves, so that's a minimal annoyance.

• Typo "preoder".

Thanks for catching. Fixed!

• Do we want to spend some time trying to beautiful axiom printing

(i.e., "J-trivial" instead of "jtrivial")?

This would be cute, indeed. I'll have a quick look if it's trivial to do. Otherwise, we can leave it for later; that will be easy to change anyway.

• I would like to see the defining properties to the category level documentation, not only in the subcategory methods.

I agree that documentation at the category level would be highly desirable. But I don't want to duplicate manually the documentation. That's a general problem that requires a general solution by having a nice automatically generated default documentation for categories with axioms. See also the related:

​http://trac.sagemath.org/ticket/16363

In the mean time the subcategory methods are the most appropriate location for the doc, since this makes it accessible for all subcategories by XXX.Jtrivial?

---

New commits:

​d09fe3b

18265: typo: preoder -> preorder

[tscrim]

Replying to nthiery:

Replying to tscrim:

• Do we want these to be axioms since these properties for subcategories do not make as much sense (e.g., for groups, L-trivial = R-trivial = J-trivial = category consisting only of the trivial group, correct?)

We want them to be axioms to interact nicely with each other: there will be many interesting combinations between the Finite / X-trivial / Unital axioms (and more will come, like Regular, ...). In fact implementing those was one of my original motivation for implementing axioms in Sage :-)

I think we should also add that an inverse H-trivial monoids implies J-trivial.

Indeed Groups().XTrivial() is, well, trivial, so that's boring. But this is only polluting the namespace of the Groups() category, not the groups themselves, so that's a minimal annoyance.

Considering there is exactly 1 X-trivial group (up to isomorphism), there won't be any additional pollution from Parent/ElementMethods either. So I agree, minimal annoyance.

• Do we want to spend some time trying to beautiful axiom printing

(i.e., "J-trivial" instead of "jtrivial")?

This would be cute, indeed. I'll have a quick look if it's trivial to do. Otherwise, we can leave it for later; that will be easy to change anyway.

Let me know.

[git]

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

​06d9bb4

18265: fixed category_with_axiom.uncamelcase to also split on single capitals; e.g. JTrivial is displayed as j trivial, not jtrivial

[nthiery]

Replying to tscrim:

I think we should also add that an inverse R-trivial monoids implies J/H-trivial.

Yes, but only when we will have the "inverse" axiom in the sense of local inverses in semigroups. Our current Inverse axiom is about having a global inverse (it's indeed annoying that we have this naming conflict, but there is nothing much we can do about it).

Of course an R-trivial monoid with a global inverse is J/H trivial, but that's not super interesting :-)

This would be cute, indeed. I'll have a quick look if it's trivial to do. Otherwise, we can leave it for later; that will be easy to change anyway.

Let me know.

I made a quick fix, so that JTrivial is displayed as j trivial and not jtrivial; it only slightly better, but requires no special casing and makes for a more consistent implementation of uncamelcasing.

It's been discussed several times that axioms like AdditiveAssociative? would be better displayed as additive-associative, to raise ambiguities in expressions such as:

    Category of associative additive commutative additive associative additive unital distributive magmas and additive magmas

This would make the j trivial into j-trivial as a by-product without any special casing. However this is a relatively invasive change (it will require updating a bunch of doctests"), so I vote for doing this in a separate ticket.

Do you agree that this is good enough for now?

[tscrim]

Replying to nthiery:

Replying to tscrim:

I think we should also add that an inverse R-trivial monoids implies J/H-trivial.

Yes, but only when we will have the "inverse" axiom in the sense of local inverses in semigroups. Our current Inverse axiom is about having a global inverse (it's indeed annoying that we have this naming conflict, but there is nothing much we can do about it).

Of course an R-trivial monoid with a global inverse is J/H trivial, but that's not super interesting :-)

I'm somewhat leaning towards having the implication for the global inverse, but considering the category of X-trivial groups is, well, trivial, I don't feel strongly about this. So if you don't feel like doing it, then you can set this to a positive review.

This would make the j trivial into j-trivial as a by-product without any special casing. However this is a relatively invasive change (it will require updating a bunch of doctests"), so I vote for doing this in a separate ticket.

Yes, I believe this should be on a separate ticket.

[git]

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

​6158f0e

18265: added the (dummy) implication H-trivial -> J-trivial for groups

[nthiery]

Replying to tscrim:

I'm somewhat leaning towards having the implication for the global inverse, but considering the category of X-trivial groups is, well, trivial, I don't feel strongly about this. So if you don't feel like doing it, then you can set this to a positive review.

Done and pushed!

[tscrim]

Thank you.