Finitely generated axiom for (mutiplicative) magmas, semigroups, monoids, groups

[nthiery]

This introduce an axiom FinitelyGeneratedAsMagma, as well as related
categories with axioms for magmas, semigroups and groups::

    sage: Groups().FinitelyGeneratedAsMagma()
    Category of finitely generated groups

For ease of notations, when there is no ambiguity, one can do::

    sage: Groups().FinitelyGenerated()
    Category of finitely generated groups

One motivation for this change (for #8678) is that finite semigroups
in Sage used to be automatically endowed with an EnumeratedSets
structure; the default enumeration is then obtained by iteratively
multiplying the semigroup generators. This forced any finite semigroup
to either implement an enumeration, or provide semigroup generators;
this was often inconvenient.

Instead, finite semigroups that provide a distinguished finite set of
generators with semigroup_generators should now explicitly declare
themselves in the category of FinitelyGeneratedSemigroups:

    sage: Semigroups().FinitelyGenerated()
    Category of finitely generated semigroups

This is a backward incompatible change.

TODO:

• Use the occasion to migrate TransitiveIdeal to RecursivelyEnumeratedSet

Depends on #10668
Depends on #15852

CC: @tscrim @sagetrac-sage-combinat @darijgr @avirmaux

Component: categories

Keywords: days64

Author: Nicolas M. Thiéry

Branch/Commit: 19ceb81

Reviewer: Travis Scrimshaw

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

[tscrim]

comment:1

Also be good for rings and algebras.

[nthiery]

Description changed:

--- 
+++ 
@@ -1 +1,31 @@
+This introduce an axiom FinitelyGeneratedAsMagma, as well as related
+categories with axioms for magmas, semigroups and groups::
 
+```
+    sage: Groups().FinitelyGeneratedAsMagma()
+    Category of finitely generated groups
+```
+For ease of notations, when there is no ambiguity, one can do::
+
+```
+    sage: Groups().FinitelyGenerated()
+    Category of finitely generated groups
+```
+
+One motivation for this change (for #8678) is that finite semigroups
+in Sage used to be automatically endowed with an ``EnumeratedSets``
+structure; the default enumeration is then obtained by iteratively
+multiplying the semigroup generators. This forced any finite semigroup
+to either implement an enumeration, or provide semigroup generators;
+this was often inconvenient.
+
+Instead, finite semigroups that provide a distinguished finite set of
+generators with ``semigroup_generators`` should now explicitly declare
+themselves in the category of ``FinitelyGeneratedSemigroups``:
+
+```
+    sage: Semigroups().FinitelyGenerated()
+    Category of finitely generated semigroups
+```
+This is a backward incompatible change.
+

[nthiery]

comment:3

Replying to @tscrim:

Also be good for rings and algebras.

Yes, and additive magmas as well. And possibly crystals, ... But I'll leave those to a later ticket. And for modules, we alreay have FiniteDimensional.

Cheers,
Nicolas

[nthiery]

Author: Nicolas M. Thiéry

[nthiery]

Description changed:

--- 
+++ 
@@ -13,15 +13,15 @@
 ```
 
 One motivation for this change (for #8678) is that finite semigroups
-in Sage used to be automatically endowed with an ``EnumeratedSets``
+in Sage used to be automatically endowed with an `EnumeratedSets`
 structure; the default enumeration is then obtained by iteratively
 multiplying the semigroup generators. This forced any finite semigroup
 to either implement an enumeration, or provide semigroup generators;
 this was often inconvenient.
 
 Instead, finite semigroups that provide a distinguished finite set of
-generators with ``semigroup_generators`` should now explicitly declare
-themselves in the category of ``FinitelyGeneratedSemigroups``:
+generators with `semigroup_generators` should now explicitly declare
+themselves in the category of `FinitelyGeneratedSemigroups`:
 
 ```
     sage: Semigroups().FinitelyGenerated()

[nthiery]

Branch: u/nthiery/categories/finitely-generated-magmas-17160

[tscrim]

comment:6

I know this isn't set for review yet, but just to note that a finite magma is automatically finitely generated. So I think we should have this reflected in the category structure; in particular, so we don't have lines like this:

Parent.__init__(self, category = Semigroups().Finite().FinitelyGenerated())

If you need someone to review it, just let me know when this is ready.

---

Last 10 new commits:

d5d3a97	10668: improved description of the HomsetsOf class
5416ba0	Add a note on the MRO used for Homset._abstract_element_class
23639a9	Fix more typos
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
f86824e	10668: documentation for HomsetsCategory.category_of + fixed typo in doctest nearby
787f461	10668: proofreading of Homsets.category_of
5f96686	17160: Merge branch 'categories/morphism-methods-10668'
f027ce2	17610: first draft of finitely generated axiom for magmas/groups/axioms

[tscrim]

Commit: f027ce2

[nthiery]

comment:7

Replying to @tscrim:

I know this isn't set for review yet,

Thanks for having looked at it!

but just to note that a finite magma is automatically finitely generated. So I think we should have this reflected in the category structure; in particular, so we don't have lines like this:

Parent.__init__(self, category = Semigroups().Finite().FinitelyGenerated())

As stated in the description, the point of the ticket is precisely to
make a distinction between finite magmas (which are indeed finitely
generated by definition), and finite monoids that are explicitly
endowed with a finite set of generators. The new axiom is about the
latter. So, above, we anyway want something like:

 Semigroups().Finite().XXX()

Granted, the current name of the axiom is misleading, and I am
hesitant about it. I also considered:

sage: Groups().Finite().WithFiniteSetOfGenerators()
Category of groups with finite set of generators

It's very explicit but feels like heavy notation; and it does not feel
as appealing as "finitely generated" which immediately rings a bell in
a mathematician's head. Also, it seems to me that being "finitely
generated" is rather useless computationally speaking if no finite set
of generators is provided; so we would not be using that nice name for
a weaker purpose anyway.

I guess that's the main design decision to be taken in this
ticket. The rest is rather straightforward.

Ah, yes, the other design decision is whether it's acceptable to break
backward compatibility. I'll be the first one to be hurt by this
change, and I believe it's worth it ...

Opinions anyone?

If you need someone to review it, just let me know when this is ready.

Ok, thanks! Darij would be a good candidate to give feedback too!

Cheers,
Nicolas

[nthiery]

comment:8

The dependency on #10668 is mostly for convenience: #10668 fixes the doctests in c3_controlled to not need to be updated everytime the category hierarchy changes.

[nthiery]

Dependencies: #10668