Closed darijgr closed 1 year ago
just documentation typos that i fixed when i was reading it
Description changed:
---
+++
@@ -1,4 +1,4 @@
-Speaking of this one:
+Speaking of these ones:
The following doctest is disabled pending :trac:`10963`::
@@ -7,4 +7,28 @@ sage: s.is_integral_domain() # not tested False
+and
+
+```
+ sage: def descent_test(n):
+ ....: DA = DescentAlgebra(QQ, n)
+ ....: NSym = NonCommutativeSymmetricFunctions(QQ)
+ ....: S = NSym.S()
+ ....: DAD = DA.D()
+ ....: w_n = DAD(set(range(1, n)))
+ ....: for I in Compositions(n):
+ ....: if not (S[I].star_involution()
+ ....: == w_n * S[I].to_descent_algebra(n) * w_n):
+ ....: return False
+ ....: return True
+ sage: all( descent_test(i) for i in range(4) ) # not tested
+ True
+ sage: all( descent_test(i) for i in range(6) ) # not tested
+ True
+
+ .. TODO::
+
+ Once :trac:`10963` is in, remove the first "not tested" above,
+ and replace the second one by "long time".
+```
Also, rebase and merge the attached doc fixes to the categories primer.
Changed dependencies from #10963, #15473 to #10963, #15473, #15476
Attachment: cat-fixes.patch.gz
[obsolete]
Branch: public/combinat/15475
Description changed:
---
+++
@@ -1,4 +1,4 @@
-Speaking of these ones:
+This branch activates two combinat doctests which were disabled due to unexplainable bugs that were fixed in #10963:
The following doctest is disabled pending :trac:`10963`::
@@ -31,4 +31,6 @@
Once :trac:10963
is in, remove the first "not tested" above,
and replace the second one by "long time".
-Also, rebase and merge the attached doc fixes to the categories primer.
+Also, a few typos in the c3_controlled doc are fixed.
+
+Disregard the attachment.
Needs_review now (finally). The review is really trivial.
Changed branch from public/combinat/15475 to public/categories/15475
Commit: a3c4cf3
Branch pushed to git repo; I updated commit sha1. New commits:
Branch fixed, but more bughuntery in progress.
Changed branch from public/categories/15475 to public/combinat/15475
Changed branch from public/combinat/15475 to public/categories/15475
Here is the bug. First, let us doctest ncsf.py with this branch normally:
darij@travis-virtualbox:~/gitsage6.2$ ./sage -bt src/sage/combinat/ncsf_qsym/ncsf.py
scons: `install' is up to date.
Updating Cython code....
Finished Cythonizing, time: 3.75 seconds.
running install
running build
running build_py
running build_ext
Executing 0 commands (using 1 thread)
Time to execute 0 commands: 0.00 seconds.
Total time spent compiling C/C++ extensions: 0.08 seconds.
running install_lib
running install_egg_info
Removing /home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage-6.3.beta2-py2.7.egg-info
Writing /home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage-6.3.beta2-py2.7.egg-info
Running doctests with ID 2014-05-25-09-34-58-fd673a84.
Doctesting 1 file.
sage -t src/sage/combinat/ncsf_qsym/ncsf.py
[679 tests, 10.12 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 10.4 seconds
cpu time: 10.1 seconds
cumulative wall time: 10.1 seconds
Now, let's do the --long test:
darij@travis-virtualbox:~/gitsage6.2$ ./sage -bt --long src/sage/combinat/ncsf_qsym/ncsf.py
scons: `install' is up to date.
Updating Cython code....
Finished Cythonizing, time: 3.88 seconds.
running install
running build
running build_py
running build_ext
Executing 0 commands (using 1 thread)
Time to execute 0 commands: 0.00 seconds.
Total time spent compiling C/C++ extensions: 0.08 seconds.
running install_lib
running install_egg_info
Removing /home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage-6.3.beta2-py2.7.egg-info
Writing /home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage-6.3.beta2-py2.7.egg-info
Running doctests with ID 2014-05-25-09-35-19-947fb6ad.
Doctesting 1 file.
sage -t --long src/sage/combinat/ncsf_qsym/ncsf.py
**********************************************************************
File "src/sage/combinat/ncsf_qsym/ncsf.py", line 1520, in sage.combinat.ncsf_qsym.ncsf.NonCommutativeSymmetricFunctions.Bases.ElementMethods.to_symmetric_group_algebra
Failed example:
all( S[C].to_symmetric_group_algebra()
== SGA4(D4(S[C].to_descent_algebra(4)))
for C in Compositions(4) )
Exception raised:
Traceback (most recent call last):
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 480, in _run
self.execute(example, compiled, test.globs)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 839, in execute
exec compiled in globs
File "<doctest sage.combinat.ncsf_qsym.ncsf.NonCommutativeSymmetricFunctions.Bases.ElementMethods.to_symmetric_group_algebra[6]>", line 3, in <module>
for C in Compositions(Integer(4)) )
File "<doctest sage.combinat.ncsf_qsym.ncsf.NonCommutativeSymmetricFunctions.Bases.ElementMethods.to_symmetric_group_algebra[6]>", line 3, in <genexpr>
for C in Compositions(Integer(4)) )
File "parent.pyx", line 1083, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:8905)
File "coerce_maps.pyx", line 95, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:4206)
File "coerce_maps.pyx", line 90, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:4113)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/combinat/free_module.py", line 1577, in _element_constructor_
raise TypeError("do not know how to make x (= %s) an element of self (=%s)"%(x,self))
TypeError: do not know how to make x (= D{} + D{1} + D{1, 2} + D{1, 2, 3} + D{1, 3} + D{2} + D{2, 3} + D{3}) an element of self (=Symmetric group algebra of order 4 over Rational Field)
**********************************************************************
1 item had failures:
1 of 8 in sage.combinat.ncsf_qsym.ncsf.NonCommutativeSymmetricFunctions.Bases.ElementMethods.to_symmetric_group_algebra
[686 tests, 1 failure, 116.10 s]
----------------------------------------------------------------------
sage -t --long src/sage/combinat/ncsf_qsym/ncsf.py # 1 doctest failed
----------------------------------------------------------------------
Total time for all tests: 116.4 seconds
cpu time: 116.0 seconds
cumulative wall time: 116.1 seconds
The failure was in a doctest which is not #long time!
There must be some coercion cache poisoning going on, probably similar to #15248, possibly connected to #10906. Any comments are welcome, since I don't have enough time for Sage these days.
OK, here is a minimal(?) way to cause the bug. Copy this code:
def descent_test(n):
DA = DescentAlgebra(QQ, n)
DAD = DA.D()
DAB = DA.B()
DAD([])
for I in Compositions(n):
DAD(DAB[I])
def maintest():
descent_test(3)
descent_test(4) # you need both 3 and 4, IN THIS ORDER, to break it!
SGA4 = SymmetricGroupAlgebra(QQ, 4)
DAB = DescentAlgebra(QQ, 4).B()
x = DAB[4]
SGA4(x)
into a .py file and attach it. Run maintest(). You will get an error:
TypeError: do not know how to make x (= B[4]) an element of self (=Symmetric group algebra of order 4 over Rational Field)
Afterwards, try doing
sage: SGA4 = SymmetricGroupAlgebra(QQ, 4)
sage: D4 = DescentAlgebra(QQ, 4).D()
sage: SGA4.has_coerce_map_from(D4)
You get False
, although in a virgin session it would be True
. So it looks like either we have problems with UniqueRepresentation and coercion, or the coercion graph has become too confusing for Sage to find a way (#15303?).
How do I debug a failed coercion? Is there a method that shows me a local coercion graph?
Also, I am no longer sure if the sfa.py issue has really been fixed or if #10963 has just kicked the can further down the road. Is there a sanity check for coercion graphs?
Changed keywords from 10963, c3 to 10963, c3, transitivity, descent algebras, symmetric functions
I feel like this is the same issue as #15309, in that calling DAD([])
makes it so that no coercions can be added dynamically (up to doing something extreme like overriding _coerce_map_from_()
). So if this is indeed the case, either we need to have better hard-coded coercions (which is the best solution, but the most work) to changing the doctests to mask this.
Indeed...
sage: DAD = DescentAlgebra(QQ, 4).D()
sage: DAD._coercions_used
False
sage: maintest()
sage: DAD._coercions_used
True
Hmm; what is _coercions_used
and what is it good for? Why can't we just remove it?
EDIT: On the other hand, commenting out self._coercions_used = True
in parent.pyx does not fix the error. But why do we have this kind of flag anyway? How on earth do we want to know if all coercions from/to a given objects are already known? Why on earth do we want this information?
Replying to @darijgr:
EDIT: On the other hand, commenting out
self._coercions_used = True
in parent.pyx does not fix the error. But why do we have this kind of flag anyway? How on earth do we want to know if all coercions from/to a given objects are already known? Why on earth do we want this information?
If I understand correctly, this flag is only relevant if we want to explicitly set a new coercion via register_coerce_map_from
or something of that kind (can't look into the code right now). The idea is that the explicit registrations happens during initialisation, whereas the automatic discovery of coerce maps by backtracking happens later and is not hampered by self._coercions_used
.
I believe the purpose of the flag is to try and prevent users from changing coercions dynamically:
sage: C = CombinatorialFreeModule(QQ, ['a','b'])
sage: D = CombinatorialFreeModule(QQ, ['a','b'])
sage: phi = C.module_morphism(D.monomial, codomain=D)
sage: C.register_coercion(phi)
sage: # D(C.monomial('a'))
'a'
sage: def f(x):
....: if x == 'a':
....: return D.monomial('b')
....: return D.monomial('a')
....:
sage: psi = C.module_morphism(f, codomain=D)
sage: C.register_coercion(psi)
sage: # D(C.monomial('a'))
'b'
Thanks@Simon, Travis.
Can anyone check if it is really this flag which causes the bug I described in comment:13? I still get the error without the flag. Thank you.
Branch pushed to git repo; I updated commit sha1. New commits:
0763ba5 | More fixes and doctests. |
I've figured it out. The issue is that because we are not holding a strong reference to SGA4
, it is being garbage collected, but DAB
has not been. As such, the new coercion map does not get recreated, so the new SGA4
doesn't know about the (dynamically created) coercion:
sage: SGA4 = SymmetricGroupAlgebra(QQ, 4); DAB = DescentAlgebra(QQ, 4).B()
sage: del SGA4
sage: import gc
sage: gc.collect()
599 # Some number, not important
sage: SGA4 = SymmetricGroupAlgebra(QQ, 4) # Now recreate it
sage: x = DAB[4]; SGA4(x)
If you remove the del SGA4
, it always works. I think the doctest runner is much more liberal about garbage collection which is why the test we had almost always failed.
Therefore I've fixed this by making the descent algebra hold a strong reference to the SGA (which it probably should irregardless).
This is now #16532.
Branch pushed to git repo; I updated commit sha1. New commits:
db24a90 | Fixed the issue...finally... Also some other minor cleanup. |
Replying to @tscrim:
I've figured it out. The issue is that because we are not holding a strong reference to
SGA4
, it is being garbage collected, butDAB
has not been. As such, the new coercion map does not get recreated, so the newSGA4
doesn't know about the (dynamically created) coercion: ... This is now #16532.
I have no time to look at the code now. But from the description at #16532, it seems to be the case that the coercion phi: A -> B
is registered by B.register_coercion(phi)
during creation of A, which would be a misuse. It should either be registered as the unique coerce embedding of A (if this makes sense) by A.register_embedding(phi)
during creation of A, or it should be registered by B.register_coercion(phi)
during creation of B (not A), or should not be registered at all, letting B._coerce_map_from_(A)
do the job.
Branch pushed to git repo; I updated commit sha1. New commits:
fb8c9c9 | Added comment about register_embedding. |
Branch pushed to git repo; I updated commit sha1. New commits:
702e7a1 | Changed to use `_coerce_map_from_` and made it more robust/general. |
Replying to @simon-king-jena:
I have no time to look at the code now. But from the description at #16532, it seems to be the case that the coercion
phi: A -> B
is registered byB.register_coercion(phi)
during creation of A, which would be a misuse. It should either be registered as the unique coerce embedding of A (if this makes sense) byA.register_embedding(phi)
during creation of A, or it should be registered byB.register_coercion(phi)
during creation of B (not A), or should not be registered at all, lettingB._coerce_map_from_(A)
do the job.
I've changed it to use _coerce_map_from_
as this was the most robust with #15303 not being done (although I had to explicitly do the function composition). Thanks for clarifying.
Darij, final review.
@tscrim: You use the canonical_embedding
, which gives a module homomorphism, as a coercion in case of coercing but distinct base rings. But is this clean? I thought module homomorphisms would only work over the same base ring. I don't see what should go wrong, but it feels like relying on indefinite behavior...
Great job hunting down the bug! It is scary that these things can make stuff break in Sage, though...
Suppose you want phi : M -> N
with M
an R
-module and N
an S
-module with a coercion R -> S
. Then phi
is a morphism in the category of R
modules. canonical_embedding()
takes care of this (albeit somewhat silently) by defining the morphism only on the basis vectors and extending by linearity (over R
in this case).
Branch pushed to git repo; I updated commit sha1. New commits:
f662ae3 | documentation fixes to canonical_embedding of symmetric group algebra (yes, these maps aren't always embeddings, and the inequality was backwards) |
Branch pushed to git repo; I updated commit sha1. New commits:
ff4e546 | oops, another doc fix |
Branch pushed to git repo; I updated commit sha1. New commits:
da61e19 | reenable SymmetricFunctions doctest |
OUCH. I just realized that I forgot to reenable the symmetric functions doctest, and not unexpectedly it is still broken. OK, this thing must be unrelated to #10963 after all. Simon, can you make sense of this?
Doctesting 1 file.
sage -t src/sage/combinat/sf/sfa.py
**********************************************************************
File "src/sage/combinat/sf/sfa.py", line 752, in sage.combinat.sf.sfa.SymmetricFunctionsBases.ParentMethods.corresponding_basis_over
Failed example:
s.corresponding_basis_over(Integers(13))
Exception raised:
Traceback (most recent call last):
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 480, in _run
self.execute(example, compiled, test.globs)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 839, in execute
exec compiled in globs
File "<doctest sage.combinat.sf.sfa.SymmetricFunctionsBases.ParentMethods.corresponding_basis_over[5]>", line 1, in <module>
s.corresponding_basis_over(Integers(Integer(13)))
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/combinat/sf/sfa.py", line 814, in corresponding_basis_over
return attrcall(self._basis)(SymmetricFunctions(R))
File "classcall_metaclass.pyx", line 330, in sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ (build/cythonized/sage/misc/classcall_metaclass.c:1282)
File "cachefunc.pyx", line 1077, in sage.misc.cachefunc.WeakCachedFunction.__call__ (build/cythonized/sage/misc/cachefunc.c:6486)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/structure/unique_representation.py", line 1021, in __classcall__
instance = typecall(cls, *args, **options)
File "classcall_metaclass.pyx", line 518, in sage.misc.classcall_metaclass.typecall (build/cythonized/sage/misc/classcall_metaclass.c:1665)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/combinat/sf/sf.py", line 763, in __init__
Parent.__init__(self, category = GradedHopfAlgebras(R).WithRealizations())
File "parent.pyx", line 358, in sage.structure.parent.Parent.__init__ (build/cythonized/sage/structure/parent.c:4247)
File "parent.pyx", line 418, in sage.structure.parent.Parent._init_category_ (build/cythonized/sage/structure/parent.c:4797)
File "lazy_attribute.pyx", line 127, in sage.misc.lazy_attribute._lazy_attribute.__get__ (build/cythonized/sage/misc/lazy_attribute.c:1353)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/categories/category.py", line 1298, in parent_class
return self._make_named_class('parent_class', 'ParentMethods')
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/categories/category.py", line 2568, in _make_named_class
cache=cache, **options)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/categories/category.py", line 1221, in _make_named_class
reduction = reduction, cache = cache)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/structure/dynamic_class.py", line 316, in dynamic_class
return dynamic_class_internal.f(name, bases, cls, reduction, doccls, prepend_cls_bases)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/structure/dynamic_class.py", line 411, in dynamic_class_internal
return metaclass(name, bases, methods)
TypeError: Cannot create a consistent method resolution
order (MRO) for bases Algebras.parent_class, Monoids.WithRealizations.parent_class, Bialgebras.parent_class, Coalgebras.WithRealizations.parent_class
**********************************************************************
File "src/sage/combinat/sf/sfa.py", line 758, in sage.combinat.sf.sfa.SymmetricFunctionsBases.ParentMethods.corresponding_basis_over
Failed example:
mj.corresponding_basis_over(Integers(13))
Exception raised:
Traceback (most recent call last):
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 480, in _run
self.execute(example, compiled, test.globs)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 839, in execute
exec compiled in globs
File "<doctest sage.combinat.sf.sfa.SymmetricFunctionsBases.ParentMethods.corresponding_basis_over[9]>", line 1, in <module>
mj.corresponding_basis_over(Integers(Integer(13)))
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/combinat/sf/sfa.py", line 814, in corresponding_basis_over
return attrcall(self._basis)(SymmetricFunctions(R))
File "classcall_metaclass.pyx", line 330, in sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ (build/cythonized/sage/misc/classcall_metaclass.c:1282)
File "cachefunc.pyx", line 1077, in sage.misc.cachefunc.WeakCachedFunction.__call__ (build/cythonized/sage/misc/cachefunc.c:6486)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/structure/unique_representation.py", line 1021, in __classcall__
instance = typecall(cls, *args, **options)
File "classcall_metaclass.pyx", line 518, in sage.misc.classcall_metaclass.typecall (build/cythonized/sage/misc/classcall_metaclass.c:1665)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/combinat/sf/sf.py", line 763, in __init__
Parent.__init__(self, category = GradedHopfAlgebras(R).WithRealizations())
File "parent.pyx", line 358, in sage.structure.parent.Parent.__init__ (build/cythonized/sage/structure/parent.c:4247)
File "parent.pyx", line 418, in sage.structure.parent.Parent._init_category_ (build/cythonized/sage/structure/parent.c:4797)
File "lazy_attribute.pyx", line 127, in sage.misc.lazy_attribute._lazy_attribute.__get__ (build/cythonized/sage/misc/lazy_attribute.c:1353)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/categories/category.py", line 1298, in parent_class
return self._make_named_class('parent_class', 'ParentMethods')
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/categories/category.py", line 2568, in _make_named_class
cache=cache, **options)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/categories/category.py", line 1221, in _make_named_class
reduction = reduction, cache = cache)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/structure/dynamic_class.py", line 316, in dynamic_class
return dynamic_class_internal.f(name, bases, cls, reduction, doccls, prepend_cls_bases)
File "/home/darij/gitsage6.2/local/lib/python2.7/site-packages/sage/structure/dynamic_class.py", line 411, in dynamic_class_internal
return metaclass(name, bases, methods)
TypeError: Cannot create a consistent method resolution
order (MRO) for bases Algebras.parent_class, Monoids.WithRealizations.parent_class, Bialgebras.parent_class, Coalgebras.WithRealizations.parent_class
**********************************************************************
1 item had failures:
2 of 43 in sage.combinat.sf.sfa.SymmetricFunctionsBases.ParentMethods.corresponding_basis_over
[881 tests, 2 failures, 19.17 s]
----------------------------------------------------------------------
sage -t src/sage/combinat/sf/sfa.py # 2 doctests failed
----------------------------------------------------------------------
New commits:
da61e19 | reenable SymmetricFunctions doctest |
Replying to @darijgr:
OUCH. I just realized that I forgot to reenable the symmetric functions doctest, and not unexpectedly it is still broken. OK, this thing must be unrelated to #10963 after all. Simon, can you make sense of this?
TypeError: Cannot create a consistent method resolution order (MRO) for bases Algebras.parent_class, Monoids.WithRealizations.parent_class, Bialgebras.parent_class, Coalgebras.WithRealizations.parent_class
Does that mean that the controlled C3 algorithm is not bullet proof, resp. that the global ordering imposed on the categories is not as it should be? Nicolas?
I'm pretty sure it's related to the category refinement that occurs for Zmod(13)
:
sage: SymmetricFunctions(Zmod(14))
Symmetric Functions over Ring of integers modulo 14
sage: SymmetricFunctions(Zmod(12)) # This isn't needed to reproduce the error
Symmetric Functions over Ring of integers modulo 12
sage: SymmetricFunctions(Zmod(13))
# Boom
sage: Rp = Zmod(13)
sage: Rp.category()
Join of Category of finite commutative rings and Category of subquotients of monoids and Category of quotients of semigroups
sage: Rp in Fields()
True
sage: Rp.category()
Join of Category of finite fields and Category of subquotients of monoids and Category of quotients of semigroups
sage: SymmetricFunctions(Rp)
Symmetric Functions over Ring of integers modulo 13
(You can remove the Rp.category()
and it will still work.) Compare this with
sage: SymmetricFunctions(Zmod(12))
Symmetric Functions over Ring of integers modulo 12
sage: SymmetricFunctions(GF(13))
Symmetric Functions over Finite Field of size 13
However, in a fresh Sage:
sage: Rp = Zmod(13)
sage: SymmetricFunctions(Rp)
Symmetric Functions over Ring of integers modulo 13
sage: Rp.category()
Join of Category of finite fields and Category of subquotients of monoids and Category of quotients of semigroups
This might be useful info (also in a fresh Sage):
sage: GradedHopfAlgebras(Zmod(14))
Join of Category of hopf algebras over Ring of integers modulo 14 and Category of graded algebras over Ring of integers modulo 14
sage: Rp = Zmod(13)
sage: GradedHopfAlgebras(Rp)
/home/travis/sage/local/lib/python2.7/site-packages/sage/categories/category.py:858: UserWarning: Inconsistent sorting results for all super categories of <class 'sage.categories.category.JoinCategory'>
self.__class__))
/home/travis/sage/local/lib/python2.7/site-packages/sage/categories/category.py:858: UserWarning: Inconsistent sorting results for all super categories of <class 'sage.categories.hopf_algebras.HopfAlgebras_with_category'>
self.__class__))
Join of Category of hopf algebras over Ring of integers modulo 13 and Category of graded algebras over Ring of integers modulo 13
sage: Rp.category()
Join of Category of finite fields and Category of subquotients of monoids and Category of quotients of semigroups
This branch activates two combinat doctests which were disabled due to unexplainable bugs that were fixed in #10963:
and
Also, a few typos in the c3_controlled doc are fixed.
Disregard the attachment.
Depends on #10963 Depends on #15473 Depends on #15476 Depends on #16678
CC: @nthiery @simon-king-jena @tscrim @sagetrac-sage-combinat
Component: categories
Keywords: 10963, c3, transitivity, descent algebras, symmetric functions
Branch/Commit: public/categories/15475 @
bf34154
Issue created by migration from https://trac.sagemath.org/ticket/15475