Opened 4 years ago
Closed 3 years ago
#15150 closed enhancement (fixed)
Implement NCSym
Reported by: | tscrim | Owned by: | sage-combinat |
---|---|---|---|
Priority: | major | Milestone: | sage-5.13 |
Component: | combinatorics | Keywords: | |
Cc: | sage-combinat, zabrocki, saliola, darij | Merged in: | sage-5.13.rc0 |
Authors: | Travis Scrimshaw | Reviewers: | Mike Zabrocki, Darij Grinberg |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #15143, #15164 | Stopgaps: |
Description (last modified by )
Implement the Hopf algebra of symmetric functions in non-commuting variables in the following bases:
- monomial m
- elementary e
- homogeneous h
- power-sum p
- x
- q
as well as the dual basis w.
Apply: trac_15150-ncsym-ts.patch
Attachments (5)
Change History (98)
comment:1 Changed 4 years ago by
comment:2 Changed 4 years ago by
Here's what I currently have. The multiplication in the dual basis isn't working correctly yet. I know there's the hopf_algebra_of_supercharacters-fs.patch
patch in the queue which seems like its targeted more for base rings of ZZ[q]
(or like Hall-Littlewoods are to Sym), and I was hoping to link them together at some point (please correct me if I'm wrong). I'd be happy to work with you on this patch.
comment:3 Changed 4 years ago by
The only problem is that I don't have much time these days to work on this. I've been meaning to implement NCSym. I'll try to take a look at what you have and see what I can offer, if anything.
As usual, thank you for your work, Travis!
comment:4 Changed 4 years ago by
Travis, what sources are you using for this? I'm asking because I haven't read anything about NCSym so far. I have a vague impression it has been introduced in one of Rota's Foundations papers, but not one that I have. A good introduction would simplify my job reviewing this by a lot.
comment:5 Changed 4 years ago by
- Cc zabrocki added; zabroki removed
Here's one of the references (Bergeron, Zabrocki): http://arxiv.org/pdf/math/0509265.pdf. I forget the other references off-hand (it's on my other computer tho), and I'll be adding all of the references to the doc as I finish it up.
comment:6 Changed 4 years ago by
- Description modified (diff)
Also I just fixed the w basis multiplication.
comment:7 Changed 4 years ago by
- Status changed from new to needs_review
Okay, the patch is now ready for first review. It has full doctest coverage and all tests pass for me. I've removed some of the coercions in the old version since I was worried about possibly breaking coercion commutative diagrams.
Some of the things I'm not perfectly happy about (but can live with currently):
- A descriptive name of the q, x, and w bases.
- No antipode for the w basis.
- Creating the
SymmetricFunctions
base object when creatingSymmetricFunctionNonCommutingVariables
in order to set up the coercion. - Is it safe to put the natural maps
Sym -> NCSym
andNSym -> NCSym
as coercions?
The references I used are included in the documentation now too.
comment:8 Changed 4 years ago by
Hi Travis, One initial comment about the NSym -> NCSym
map. It is dangerous to call it "the natural" map from NSym
to NCSym
. It is one of many. There does not seem to be a reason to favor the map which sends the complete generators to the complete generators. If you were to send the elementary generators to the elementary generators you get a map which is equally compelling and (unfortunately) they are not the same map.
comment:9 Changed 4 years ago by
New version rebased over changes in #15143 and removes the word "natural" and instead states that it is the map which fixes Sym
.
comment:10 Changed 4 years ago by
Hi Travis,
What patches and version do you have applied? I get fuzz on the file sage/combinat/ncsf_qsym/ncsf.py and doc tests failing in ncsym.py (seemingly) because the output displays in a different order. We may need to put a dependency with other patches that touch ncsf.py. I am currently running on sage-5.12.beta5 and only #15143 applied.
comment:11 Changed 4 years ago by
Hey Mike,
I have 5.12.beta3 in the combinat queue, but the fuzz is likely due to #15164 (which I'm planning to review soon). What type of fuzz do you get? If it's 0 or 1, we don't need to put it down as a dependency.
I'll build 5.12.beta5 today and see if I also get doctest failing.
Best,
Travis
comment:12 Changed 4 years ago by
You are right that the fuzz is disappears by applying #15164
I get 4 doctest failures on ncsym.py. They are minor, but I don't know why I see them and you don't (so it doesn't seem like a good idea to change them). They are on lines 248, 438, 633, 737 and for instance one is
File "sage/combinat/ncsym/ncsym.py", line 633, in sage.combinat.ncsym.ncsym.SymmetricFunctionsNonCommutingVariables.elementary.Element.omega Failed example: elt = e[[1,3],[2]].omega(); elt Expected: -e{{1, 3}, {2}} + 2*e{{1}, {2}, {3}} Got: 2*e{{1}, {2}, {3}} - e{{1, 3}, {2}}
comment:13 Changed 4 years ago by
I would have thought that the total ordering on set partitions in #15143 would have CombinatorialFreeModule
give a unique sorting on the elements:
sage: SetPartition([[1,3],[2]]) < SetPartition([[1],[2],[3]]) False sage: SetPartition([[1,3],[2]]) > SetPartition([[1],[2],[3]]) True sage: SetPartition([[1],[2],[3]]) < SetPartition([[1,3],[2]]) True sage: SetPartition([[1],[2],[3]]) > SetPartition([[1,3],[2]]) False
My guess as to why we're getting different output is a failure in the comparisons (I didn't see any tickets that seemed like would change the output of linear_comb()
). Try running:
sage: e = SymmetricFunctionsNonCommutingVariables(QQ).e() sage: e.print_options() {'bracket': False, 'latex_bracket': False, 'latex_prefix': None, 'latex_scalar_mult': None, 'monomial_cmp': <function cmp>, 'prefix': 'e', 'scalar_mult': '*', 'tensor_symbol': None} sage: cmp(SetPartition([[1],[2],[3]]), SetPartition([[1,3],[2]])) -1 sage: elt = 2*e[[1],[2],[3]] - e[[1,3],[2]] sage: L = elt._monomial_coefficients.items() sage: L.sort(cmp=cmp, key=lambda (x,y): x) sage: L [({{1, 3}, {2}}, -1), ({{1}, {2}, {3}}, 2)]
Do you get anything different, in particular the last one?
comment:14 Changed 4 years ago by
I do get something different, but all of the comparisons are the same. For the last one I get:
[({{1}, {2}, {3}}, 2), ({{1, 3}, {2}}, -1)]
Any idea why?
comment:15 Changed 4 years ago by
This is why:
sage: A = SetPartition([[1],[2],[3]]) sage: B = SetPartition([[1,3],[2]]) sage: cmp(A, B) -1 sage: cmp(B, A) -1
The cmp
is not correctly using the rich comparisons because ClonableArray
has (in effect) a __cmp__
function which calls the underlying list (which contains Set
objects which don't compare as intended)...
I'm fixing this right now.
comment:16 Changed 4 years ago by
Okay, now it should be consistent.
sage: A = SetPartition([[1],[2],[3]]) sage: B = SetPartition([[1,3],[2]]) sage: cmp(A, B) -1 sage: cmp(B, A) 1
I added a __cmp__()
method to SetPartition
to override the behavior of ClonableArray
.
Changed 4 years ago by
comment:17 Changed 4 years ago by
OK. Thanks for fixing that. I'm looking over the patch and I have some initial changes where the multiplication uses the pipe function and the product is implemented in the q
basis.
The change of basis from q
to x
or vice versa is slow and so ideally I would like to improve this.
I think that line 180 from ncsym.py
is wrong. There should be no morphism from NCSym to Sym, but there is a projection. There is however a morphism from DNCSym to Sym.
DNCSym is similar to quasi-symmetric functions so that if you add the right elements together (say some linear combination of the w
basis) then you have an element of Sym.
comment:18 Changed 4 years ago by
Another thing that was bothering me was that x[[1,2],[3]]
is ok, but x([[1,2],[3]])
is not. Both should be ok. I think that this should be an easy fix.
comment:19 Changed 4 years ago by
Some random comments on ncsym.py.
The ring of symmetric functions in non-commutative variables, which is not to be confused with the :class:`non-commutative symmetric functions<NonCommutativeSymmetricFunctions>`, are polynomials in `n` non-commuting variables `{\bf k}[x_1, x_2, \ldots, x_n]` where the dimension of the subspace of elements of degree `k` is equal to the number of compositions of `k` (with less than `n` parts).
If the variables are non-commuting, use angular rather than square brackets. Also, I assume you want infinitely many variables? And do you really want compositions?
Typo:
Grothendeick
Old-style arXiv references like this:
:arxiv:`0208168`
should have a "math/" in front of them, I believe (also, I'd add a version number, in this case math/0208168v2).
What is the \wedge operation on set partitions? It is used but not defined. If it's the one from the Bergeron-Zabrocki paper, it is simply the meet of set partitions (aka __mul__
) and should be explained as such.
On the right hand side of
S(\mathbf{p}_A) = \sum_{\gamma} (-1)^{\ell(\gamma)} \gamma[A]
don't you mean to say p_{\gamma[A]}
rather than \gamma[A]
? And on the next line, do you mean to say of `[\ell(A)]`
instead of of length `\ell(A)`
?
Similarly here:
p(A) = \sum_{\gamma} (-1)^{\ell(\gamma)-1} \gamma[A]
I assume that "strictly coarser" in
where we sum over all strictly coarser set partitions `B`.
refers to the relation of strict coarsening as defined in set_partition.py
. If so, please say this explicitly, as the notation is slightly counterintuitive (one normally thinks "strictly coarser" means "coarser and not equal").
I'll eventually have a closer look at the patch if only to understand how exactly internal-coproduct-by-coercion works (for use in NSym); I cannot promise that I will ever give this an actual review. Nevertheless, great work here, Travis.
comment:20 Changed 4 years ago by
- Description modified (diff)
Here's the new version of the patch which (hopefully) takes care of all of Darij's comments. How the internal_coproduct*
works is a trick with lazy_attribute
which *_by_coercion()
creates the correct morphism object if *_on_basis()
is not implemented and so it behaves like a method.
I've removed the coercion from NCSym
to Sym
since it is not a Hopf morphism, which is a requirement for it to be a coercion. I've fixed the input to accept x([[1,3],[2]])
as well.
Currently to get from x
to q
(or vice versa) there's a few coercions going on, and I don't know of a way to go between them directly. (Data suggests that x(q[A])
is a sum over some subset of set partitions with all coefficients occurring (-1)^{nest(A)}.)
For DNCSym
, is there a way to express an element in the w basis as a polynomial? Currently I have a map from Sym
to DNCSym
which is at least (appears to me to be) an algebra morphism (see the sum_of_partitions()
method). Is this a Hopf morphism and is the map from DNCSym
to Sym
the inverse of this map?
Thank you all for looking at this patch,
Travis
Edit - let's see if the patchbot catches it in an edited message:
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:21 Changed 4 years ago by
Hi Travis, Is it possible that this is the same patch as before?
comment:22 Changed 4 years ago by
I think I uploaded the patch from my beta3 install instead of my beta5. Sorry about that. Here's the new one.
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:23 follow-up: ↓ 24 Changed 4 years ago by
So about your question if DNCSym
can be realized in the polynomial algebra. The answer is 'probably' but no one has ever done this. Maybe you can make a guess at the realization by what I will write. I will guess that the dual to the complete basis is some sort of monomial basis (the w
basis is the dual to the m
basis).
The morphism from DNCSym
into Sym
is 'the coefficient of w_A
in h_\lambda
is equal to the coefficient of m_\lambda
in chi(m_A)
.' Therefore,
\sum_{A} A^{!} w_A = h_\lambda
where the sum is over A
with set partitions with part lengths a partition \lambda
and the A^{!}
notation is from Rosas / Sagan p. 4.
comment:24 in reply to: ↑ 23 Changed 4 years ago by
Replying to zabrocki:
So about your question if
DNCSym
can be realized in the polynomial algebra. The answer is 'probably' but no one has ever done this. Maybe you can make a guess at the realization by what I will write. I will guess that the dual to the complete basis is some sort of monomial basis (thew
basis is the dual to them
basis).The morphism from
DNCSym
intoSym
is 'the coefficient ofw_A
inh_\lambda
is equal to the coefficient ofm_\lambda
inchi(m_A)
.' Therefore,\sum_{A} A^{!} w_A = h_\lambdawhere the sum is over
A
with set partitions with part lengths a partition\lambda
and theA^{!}
notation is from Rosas / Sagan p. 4.
Okay, this is describing the image of the map I currently have implemented:
sage: h = SymmetricFunctions(QQ).h() sage: w = SymmetricFunctionsNonCommutingVariables(QQ).dual().w() sage: w(h[2,1,1]) 2*w{{1}, {2}, {3, 4}} + 2*w{{1}, {2, 3}, {4}} + 2*w{{1}, {2, 4}, {3}} + 2*w{{1, 2}, {3}, {4}} + 2*w{{1, 3}, {2}, {4}} + 2*w{{1, 4}, {2}, {3}}
This map is respecting the multiplication
sage: w[[1,2]] * w[[1]] * w[[1]] 2*w{{1}, {2}, {3, 4}} + 2*w{{1}, {2, 3}, {4}} + 2*w{{1}, {2, 4}, {3}} + 2*w{{1, 2}, {3}, {4}} + 2*w{{1, 3}, {2}, {4}} + 2*w{{1, 4}, {2}, {3}}
so we can at least get w[[1,2,...,n]] = h[n]
as the correct expansion. However this does not seem straightforward to me in general as we have
sage: h[2,1,1].expand(2) x0^4 + 3*x0^3*x1 + 4*x0^2*x1^2 + 3*x0*x1^3 + x1^4
If it does work, it probably uses crossings and/or nestings, but I don't see it.
Anyways, do you think I should add a method is_symmetric_function()
and/or to_symmetric_function()
for the dual bases?
Also I found a bug with the expansion, in that SetPartition
was not always living in the correct parent when taking inf
or sup
. I also added to_symmetric_function
for the e, h, and p NCSym
basis to return the correct object in the e, h, and p Sym
basis resp.
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:25 Changed 4 years ago by
You are right that the polynomial realization of the w
basis may not be obvious. I suspect that you will have a better hope of guessing at what the polynomial realization is by looking at the dual of the h basis.
I think that there should be a method for is_symmetric_function()
for the bases of DNCSym
. I don't think that to_symmetric_function()
makes sense in that space.
comment:26 Changed 4 years ago by
for the patchbots:
apply only trac_15150-ncsym-ts.patch
comment:27 Changed 4 years ago by
for the patchbots:
apply only trac_15150-ncsym-ts.patch
comment:28 Changed 4 years ago by
Patchbots are dummy ?
apply trac_15150-ncsym-ts.patch
comment:29 Changed 4 years ago by
"Also I found a bug with the expansion, in that SetPartition? was not always living in the correct parent when taking inf or sup."
How that?
sage: P = SetPartition([[3,1],[2]]) sage: parent(P) Set partitions sage: Q = SetPartition([[1,2],[3]]) sage: Q.inf(P) {{1}, {2}, {3}} sage: parent(Q.inf(P)) Set partitions sage: parent(Q.sup(P)) Set partitions sage: P = SetPartitions(3)(P) sage: P {{1, 3}, {2}} sage: parent(P) Set partitions of {1, 2, 3} sage: Q = SetPartitions(3)(Q) sage: parent(Q) Set partitions of {1, 2, 3} sage: P.inf(Q) {{1}, {2}, {3}} sage: parent(P.inf(Q)) Set partitions of {1, 2, 3} sage: parent(P.sup(Q)) Set partitions of {1, 2, 3}
comment:30 Changed 4 years ago by
Try it with SetPartitions(3, [2,1,1])
.
comment:31 Changed 4 years ago by
Oh, that's ugly (although I hope you mean SetPartitions(4, [2,1,1])
. I'm wondering if we need a parent for set partitions with given type at all? I can think of very few maps which preserve the type, and it's not just inf and sup that fail:
sage: P = SetPartitions(4, [2,1,1]) sage: x = P[0] sage: x.coarsenings() [...] AssertionError: sage: x.refinements() [...] AssertionError:
comment:32 Changed 4 years ago by
This thing actually happens not only with set partitions. Any idea on how to avoid it on a bigger scale?
sage: P = Permutations(recoils=[2,3]) sage: u = P[1] sage: u.complement() [5, 3, 2, 4, 1] sage: parent(u.complement()) Standard permutations whose recoils composition is [2, 3]
The only reason why this doesn't blow up is that the class of permutations whose recoils composition is a given composition is liberal to invalid input.
Similarly:
sage: P = Permutations(5, avoiding=[1,2,3]) sage: parent(P[25].complement()) Standard permutations of 5 avoiding [1, 2, 3] sage: P[25].complement() [3, 1, 4, 2, 5]
comment:33 Changed 4 years ago by
Ah, yes I did. I'd want the parent so as to provide an object to iterate over set partitions with a given shape. I thought I also fixed the coarsenings
and refinements
in this patch as well.
Florent was working on a related issue to this in the set factories ticket #10194 and we could tweak the concept to fix this by saying that it's parents must not contain certain conditions. As a current work around, we'd have to revert to a general parent on any method that does not preserve all conditions. I'm worried that this might end up having repercussions in other parts of Sage (mainly symmetric functions).
comment:34 Changed 4 years ago by
Similarly:
sage: C = Compositions(6, inner=[2,2]) sage: c1 = C[1] sage: c1 [3, 3] sage: c1.conjugate() [1, 1, 2, 1, 1] sage: parent(c1.conjugate()) Compositions of the integer 6 satisfying constraints inner=[2, 2] sage: c1.conjugate() in parent(c1.conjugate()) False
Lack of input checking again saves this.
comment:35 Changed 4 years ago by
Hey Mike,
I've added an is_symmetric()
method to the w basis.
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:36 Changed 4 years ago by
- Status changed from needs_review to needs_work
many failing doctests
comment:37 Changed 4 years ago by
- Status changed from needs_work to needs_review
Now with fixed doctests.
comment:38 Changed 4 years ago by
Hi Travis,
So far I am focusing in on pieces of functionality. It doesn't quite seem to work as I expect. The doc string w.sum_of_partitions?
does not seem to agree with what it does since it is actually a sum with coefficients.
I was trying to figure out how to coerce f=w[[1,2],[3]]+w[[1,3],[2]]+w[[2,3],[1]]
to the h-basis and I don't see a doc-string and what I tried doesn't seem to work anyway. DNCSym.to_symmetric_function?
gives an error and when I try either h(f)
or DNCSym.to_symmetric_function(f)
, both give the same error:
TypeError Traceback (most recent call last) <ipython-input-34-98785946d5a3> in <module>() ----> 1 DNCSym.to_symmetric_function(f) /Applications/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/categories/map.so in sage.categories.map.Map.__call__ (sage/categories/map.c:4018)() /Applications/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/categories/morphism.so in sage.categories.morphism.SetMorphism._call_ (sage/categories/morphism.c:4837)() /Applications/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/categories/modules_with_basis.pyc in preimage(self, f) 1711 j_preimage = j 1712 else: -> 1713 j_preimage = self._inverse_on_support(j) 1714 if j_preimage is None: 1715 raise ValueError, "%s is not in the image of %s"%(f, self) /Applications/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/combinat/ncsym/dual.pyc in _par_to_set_par(self, la) 287 ret = [] 288 for i in sorted(la): --> 289 ret += [range(cur, cur+i)] 290 cur += i 291 return SetPartitions()(ret) TypeError: unsupported operand type(s) for +: 'int' and 'Set_object_enumerated_with_category'
What should I do in order to send my element f
into the symmetric functions?
comment:39 Changed 4 years ago by
Hey Mike,
You use the new version of the patch which corrects all of the above. I also added a method to_symmetric_function()
to the w
basis and, to be consistent with QSym
, to its elements. Just let me know everything you'd want to see this patch do.
Best,
Travis
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:40 Changed 3 years ago by
Overall the functionality looks good. You covered a lot of ground for a first implementation. I don't think I will suggest other functionality, but I will check the ones you have.
What I can see of the map from Sym -> NCSym* seems to work well.
How come you import SymmetricFunctionsNonCommutingVariables
into the namespace, but not the dual? It seems as though we can only access it through NCSym.dual()
. Is it because there is no name for the dual space? Actually it is called ΠQSym in "Commutative Combinatorial Hopf Algebras" http://arxiv.org/abs/math/0605262
. I think that we can do better than ΠQSym for a name. This reference seems to realize this space in the ring of polynomials (see equations (23) and (55) for this realization), but not clearly where Sym is a subalgebra.
comment:41 Changed 3 years ago by
Sorry, but what does this mean:
496 def to_ncsym_on_basis(self, I): 497 r""" 498 The image of the basis element indexed by ``I`` under the 499 map to the symmetric functions in non-commuting 500 variables that fixes the usual symmetric functions.
How can a map from NSym to something fix the usual symmetric functions if the latter aren't a subspace of NSym? (Same question for both to_ncsym
methods.)
Oooh, I think you mean "commutes with the projection onto the usual symmetric functions". Maybe clarify this?
comment:42 Changed 3 years ago by
Hey Mike,
The biggest thing why it's not imported is the name, I didn't think just calling it DualSymmetricFunctionsNonCommutingVariables
was more descriptive than calling SymmetricFunctionsNonCommutingVariables(QQ).dual()
(and it's not much shorter to call). I'm not 100% happy with the name (being the global namespace) since I seem to want to attach dual to function, as in the dual symmetric functions (as in linear functionals) in non-commuting variables. I know it doesn't make much sense, but it sounded more descriptive than SymmetricFunctionsNonCommutingVariablesDual
. I'll import Dual*
in the next version unless we come up with a better name. I can't think of one right now... Franco, you have any ideas as well?
I'll use http://arxiv.org/abs/math/0605262 to give a realization and also define a coercion from QSym
into DNCSym
.
Hey Darij,
Yes, up to abuse of labels on commutative diagrams. I'll change it to explicitly state that `\chi \circ p = \phi` on Sym
(up to function names).
Best,
Travis
comment:43 Changed 3 years ago by
New patch that Mike and I have talked about (removes the QSym stuff and the name for the Hopf dual) and with Darij's docstring improvements folded in.
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:44 Changed 3 years ago by
Should be a one-line edit:
********************************************************************** File "devel/sage/sage/combinat/ncsym/ncsym.py", line 248, in sage.combinat.ncsym.ncsym.SymmetricFunctionsNonCommutingVariables.monomial.from_symmetric_function Failed example: elt = m.from_symmetric_function(mon[2,1,1]); elt Exception raised: Traceback (most recent call last): File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 479, in _run self.execute(example, compiled, test.globs) File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 838, in execute exec compiled in globs File "<doctest sage.combinat.ncsym.ncsym.SymmetricFunctionsNonCommutingVariables.monomial.from_symmetric_function[2]>", line 1, in <module> elt = m.from_symmetric_function(mon[Integer(2),Integer(1),Integer(1)]); elt File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/combinat/ncsym/ncsym.py", line 255, in from_symmetric_function return self.sum([c * self.sum_of_partitions(i) for i,c in m(f)]) File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/combinat/ncsym/ncsym.py", line 471, in sum_of_partitions la = Partition(la) # Make sure it is a partition NameError: global name 'Partition' is not defined
comment:45 Changed 3 years ago by
Whoops. Fixed.
Apply: trac_15150-ncsym-ts.patch
comment:46 Changed 3 years ago by
Sorry, more stuff coming up (and I can't edit right now since I'm running doctests):
********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 346, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.expand Failed example: w[[1,3],[2]].expand(4) Expected: x0*x1*x0 + x0*x2*x0 + x0*x3*x0 + x1*x0*x1 + x1*x2*x1 + x1*x3*x1 + x2*x0*x2 + x2*x1*x2 + x2*x3*x2 + x3*x0*x3 + x3*x1*x3 + x3*x2*x3 Got: x02*x11*x20 + x03*x11*x30 + x03*x22*x30 + x13*x22*x31 ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 353, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.expand Failed example: w[[1],[2,3]].expand(3, letter='y') Expected: y0*y1^2 + y0*y2^2 + y1*y0^2 + y1*y2^2 + y2*y0^2 + y2*y1^2 Got: y00*y12*y21 ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 492, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.is_quasisymmetric Failed example: elt = w.sum_of_compositions([2,1,1]) Exception raised: Traceback (most recent call last): File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 479, in _run self.execute(example, compiled, test.globs) File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 838, in execute exec compiled in globs File "<doctest sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.is_quasisymmetric[1]>", line 1, in <module> elt = w.sum_of_compositions([Integer(2),Integer(1),Integer(1)]) File "parent.pyx", line 761, in sage.structure.parent.Parent.__getattr__ (sage/structure/parent.c:6823) File "misc.pyx", line 251, in sage.structure.misc.getattr_from_other_class (sage/structure/misc.c:1606) AttributeError: 'SymmetricFunctionsNonCommutingVariablesDual.w_with_category' object has no attribute 'sum_of_compositions' ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 493, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.is_quasisymmetric Failed example: elt.is_quasisymmetric() Exception raised: Traceback (most recent call last): File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 479, in _run self.execute(example, compiled, test.globs) File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 838, in execute exec compiled in globs File "<doctest sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.is_quasisymmetric[2]>", line 1, in <module> elt.is_quasisymmetric() NameError: name 'elt' is not defined ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 495, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.is_quasisymmetric Failed example: elt -= 3*w.sum_of_compositions([1,1]) Exception raised: Traceback (most recent call last): File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 479, in _run self.execute(example, compiled, test.globs) File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 838, in execute exec compiled in globs File "<doctest sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.is_quasisymmetric[3]>", line 1, in <module> elt -= Integer(3)*w.sum_of_compositions([Integer(1),Integer(1)]) NameError: name 'elt' is not defined ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 496, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.is_quasisymmetric Failed example: elt.is_quasisymmetric() Exception raised: Traceback (most recent call last): File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 479, in _run self.execute(example, compiled, test.globs) File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 838, in execute exec compiled in globs File "<doctest sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.is_quasisymmetric[4]>", line 1, in <module> elt.is_quasisymmetric() NameError: name 'elt' is not defined ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 538, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.to_quasisymmetric_function Failed example: elt.to_quassymmetric_function() Exception raised: Traceback (most recent call last): File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 479, in _run self.execute(example, compiled, test.globs) File "/home/darij/sage-5.12.beta5/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 838, in execute exec compiled in globs File "<doctest sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.to_quasisymmetric_function[2]>", line 1, in <module> elt.to_quassymmetric_function() File "element.pyx", line 344, in sage.structure.element.Element.__getattr__ (sage/structure/element.c:3871) File "misc.pyx", line 251, in sage.structure.misc.getattr_from_other_class (sage/structure/misc.c:1606) AttributeError: 'SymmetricFunctionsNonCommutingVariablesDual.w_with_category.element_class' object has no attribute 'to_quassymmetric_function' ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 541, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.to_quasisymmetric_function Failed example: elt.to_quasisymmetric_function() Expected: 1/2*h[2, 1, 1] Got: M[1, 1, 2] + M[1, 2, 1] + M[2, 1, 1] ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 549, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.to_quasisymmetric_function Failed example: w([]).to_quasisymmetric_function() Expected: h[] Got: M[] ********************************************************************** File "devel/sage/sage/combinat/ncsym/dual.py", line 551, in sage.combinat.ncsym.dual.SymmetricFunctionsNonCommutingVariablesDual.w.Element.to_quasisymmetric_function Failed example: (2*w([])).to_quasisymmetric_function() Expected: 2*h[] Got: 2*M[] **********************************************************************
This is still the old file, since I didn't want to pop and push during doctesting.
comment:47 follow-up: ↓ 48 Changed 3 years ago by
I didn't separate everything off as I thought I did. I also made the expansion live in the correct parent (in HNT it is the quotient of a polynomial ring).
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:48 in reply to: ↑ 47 Changed 3 years ago by
Here are some doc changes, but a lot of methods need OUTPUT as well as INPUT. Remember how I said "I don't think I will suggest other functionality..."? I was wrong. One thing that I realized that was missing was a duality_pairing
function. I have a patch to add this, but I need to add documentation yet. I'll try to do this shortly.
Changed 3 years ago by
comment:49 Changed 3 years ago by
New version with both of Mike's patches folded in and functions documented, along with refactoring the categories to a common super category to not duplicate code.
comment:50 Changed 3 years ago by
Hi Travis,
I was looking at the method from_symmetric_function
and I want to make sure that I understand. It is just a linear map of one vector space to another, right? It does not preserve the product or the coproduct structure if I understand it.
comment:51 Changed 3 years ago by
Hey Mike.
Yes. It is more about it being a section of the natural projection and working with the map with NSym.
comment:52 Changed 3 years ago by
Here is one that I can see needs to be fixed.
sage: Sp = SymmetricFunctions(QQ).p() sage: Np = SymmetricFunctionsNonCommutingVariables(QQ).p() sage: Nh = SymmetricFunctionsNonCommutingVariables(QQ).h() sage: Sp(Nh(Np([[1,4],[2,3]])).to_symmetric_function()) 45/2*p[1, 1, 1, 1] - p[2, 1, 1] + 1/2*p[2, 2] sage: Np([[1,4],[2,3]]).to_symmetric_function() p[2, 2] sage: Ne = SymmetricFunctionsNonCommutingVariables(QQ).e() sage: Sp(Ne(Np([[1,4],[2,3]])).to_symmetric_function()) 45/2*p[1, 1, 1, 1] + p[2, 1, 1] + 1/2*p[2, 2]
With m, q, x the coercion is consistent.
I am fairly sure the problem is with the projection to_symmetric_function
in the h and the e bases.
comment:53 Changed 3 years ago by
more doc changes
comment:54 Changed 3 years ago by
Hey Mike,
I've folded in your latest review patch, fixed the projection in the h and e bases (I wasn't scaling by the correct constant), and added some exposition to the NCSym
class.
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:55 Changed 3 years ago by
- Dependencies changed from #15143 to #15143, #15164
comment:56 Changed 3 years ago by
Sorry I had to put this aside for a while. I factored out product_on_basis
and moved it to bases.py
since the product is the same for all bases except the monomial basis. Added a few more doc changes. I think that there is more to do, but we are getting close.
comment:57 Changed 3 years ago by
This version includes changes to dual.py
. I deleted the function _set_par_to_par
because it didn't make sense and the documentation was wrong and it could be replaced with lambda A: A.shape()
.
comment:58 Changed 3 years ago by
Hmm. Am I seeing it right that you defined the product to be piping on every basis unless overshadowed explicitly? A bit of an trap if you ask me.
Also:
392 The expansion of an element of the `\mathbf{w}` basis is 393 given by equations (26) and (55) in [HNT06]_.
The formula numbers refer to a version of the paper other than the one referenced (arXiv; by the way, please add a version number).
comment:59 Changed 3 years ago by
I created a category of multiplicative bases and put the product_on_basis
there. In theory, calculations can be sped up by applying homomorphisms to irreducible components of basis elements.
comment:60 Changed 3 years ago by
But it's in class NCSymBases(Category_realization_of_parent)
, not in some hypothetical class MultiplicativeNCSymBases(NCSymBases)
right? Oooh, I see, this nevertheless means the multiplicative bases only, while all the others go through the NCSymBasis_abstract
class. But IMHO this is confusing, and could be clarified at least in the class docstrings if not in the names of the classes...
comment:61 Changed 3 years ago by
The method _set_par_to_par
is needed because does a little bit more than just return the shape and is needed for the [inverse] coercion. The method _set_par_to_par()
in effect takes a subset of set partitions which are in bijection with partitions and corresponds to leading terms in the coercion.
With Mike's patch we have:
sage: w = SymmetricFunctionsNonCommutingVariablesDual(QQ).w() sage: h = SymmetricFunctions(QQ).h() sage: h(w[[1,3],[2]]) --------------------------------------------------------------------------- AssertionError Traceback (most recent call last) <ipython-input-3-5d0ec5476c79> in <module>() ----> 1 h(w[[Integer(1),Integer(3)],[Integer(2)]]) /home/travis/sage-5.13.beta0/local/lib/python2.7/site-packages/sage/structure/parent.so in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:8372)() /home/travis/sage-5.13.beta0/local/lib/python2.7/site-packages/sage/categories/morphism.so in sage.categories.morphism.SetMorphism._call_ (sage/categories/morphism.c:4837)() /home/travis/sage-5.13.beta0/local/lib/python2.7/site-packages/sage/categories/modules_with_basis.pyc in preimage(self, f) 1715 raise ValueError, "%s is not in the image of %s"%(f, self) 1716 s = map(j_preimage) -> 1717 assert j == self._dominant_item(s)[0] 1718 1719 if not self._unitriangular: AssertionError:
While it shouldn't work, it is giving the wrong error.
I've folded in your latest patch Mike, but reinstated _set_par_to_par
with some documentation changes and some doctests. Hopefully it is more clear what it does, but perhaps the method could be renamed.
But it's in class NCSymBases(Category_realization_of_parent), not in some hypothetical class MultiplicativeNCSymBases(NCSymBases) right? Oooh, I see, this nevertheless means the multiplicative bases only, while all the others go through the NCSymBasis_abstract class. But IMHO this is confusing, and could be clarified at least in the class docstrings if not in the names of the classes...
Not quite. We need the NCSymBasis_abstract
class to overwrite the _element_constructor_
from Parent
. This is not a category object, and all bases inherit from this (as classes). The different categories are used as a slightly different type of abstraction, which includes (in a sense) a mathematical organization.
I've also made the w basis inherit from NCSymBasis_abstract
.
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:62 Changed 3 years ago by
Hmm. I still don't get _set_par_to_par
. Where does the \lambda_i \leq \lambda_{i+1}
come in?
sage: w = SymmetricFunctionsNonCommutingVariables(QQ).dual().w() sage: h = SymmetricFunctions(QQ).h() sage: w._set_par_to_par(SetPartition([[1],[2],[3,4,5]])) [3, 1, 1] sage: w._set_par_to_par(SetPartition([[1,2,3],[4],[5]])) [3, 1, 1] sage: w._set_par_to_par(SetPartition([[1],[2,3,4],[5]])) [3, 1, 1] sage: w._set_par_to_par(SetPartition([[1],[2,3,5],[4]])) sage: h(w[[1,2],[3]]) --------------------------------------------------------------------------- AssertionError Traceback (most recent call last) ... AssertionError: sage: h(w[[1],[2,3]]) --------------------------------------------------------------------------- AssertionError Traceback (most recent call last) ... AssertionError: sage: h(w[[1,3],[2]]) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) ... ValueError: w{{1, 3}, {2}} is not in the image of Generic morphism: From: Symmetric Functions over Rational Field in the homogeneous basis To: Dual symmetric functions in non-commuting variables over the Rational Field in the w basis sage:
Why is the last one a ValueError
and the others are assertion errors?
comment:63 Changed 3 years ago by
There's two problems, the first is the morphism should be the other triangular and the second is the _set_par_to_par()
is not restrictive enough. I'll be fixing this now.
comment:64 Changed 3 years ago by
Okay, fixed. They all return ValueError
s now and I'm now using the ordering on lambda_i
in the method.
comment:65 Changed 3 years ago by
There seems to be a problem with coercion for bases other than than h
.
sage: w = SymmetricFunctionsNonCommutingVariablesDual(QQ).w() sage: e = SymmetricFunctions(QQ).e() sage: e(w(e[2,1])) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-4-66ec535e7d35> in <module>() ----> 1 e(w(e[Integer(2),Integer(1)])) /Applications/sage/local/lib/python2.7/site-packages/sage/structure/parent.so in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:8372)() /Applications/sage/local/lib/python2.7/site-packages/sage/structure/coerce_maps.so in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3856)() /Applications/sage/local/lib/python2.7/site-packages/sage/structure/coerce_maps.so in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3757)() /Applications/sage/local/lib/python2.7/site-packages/sage/combinat/sf/classical.pyc in _element_constructor_(self, x) 327 return eclass(self, {sage.combinat.partition.Partition([]):R(x)}) 328 except StandardError: --> 329 raise TypeError, "do not know how to make x (= %s) an element of self"%(x) 330 331 # This subclass is currently needed for the test above: TypeError: do not know how to make x (= 6*w{{1}, {2}, {3}} - w{{1}, {2, 3}} - w{{1, 2}, {3}} - w{{1, 3}, {2}}) an element of self sage: h = SymmetricFunctions(QQ).h() sage: e(h(w(e[2,1]))) e[2, 1]
comment:66 Changed 3 years ago by
A few minor changes in whitespace and pyflakes warnings.
comment:67 Changed 3 years ago by
Mike, you're trying to coerce from a basis of dual NCSym to a basis of Sym? Should that really be a coercion? That would give a noncommutative coercion graph...
comment:68 Changed 3 years ago by
To my eye, the problem is the doc tests. I see examples of coercion through the h
basis rather than the use of the to_symmetric_function
method. Reading those doc-tests I suspected that the h
basis is not the only portal and I was wrong.
sage: w = SymmetricFunctionsNonCommutingVariablesDual(QQ).w() sage: e = SymmetricFunctions(QQ).e() sage: w(e[2,1]).to_symmetric_function() h[1, 1, 1] - h[2, 1]
comment:69 Changed 3 years ago by
OK, this thing is implemented as a conversion (rightly -- it can't be a coercion), whence there is no automatic path discovery. But the docstring is claiming it's a coercion, and could be more explicit about it only leading to h
.
comment:70 follow-up: ↓ 73 Changed 3 years ago by
I'm not sure if I should be too concerned because the doc tests are in a hidden function and they are there to test if that coercion doesn't work, not to demonstrate how to coerce between NCSym^{*} and Sym. I tried to make it *slightly* clearer by changing the doc test.
I also changed the following because I don't think it is right:
There is also a natural projection to the usual symmetric functions by letting the variables commute. This projection does *not* preserve the product nor coproduct stucture, but instead is just a module morphism.
I think the slice defined in from_symmetric_function
does not preserve the Hopf structure, but the projection preserves both product and coproduct.
comment:71 Changed 3 years ago by
I added a few doc tests that hopefully clarifies the purpose of from_symmetric_function
.
comment:72 Changed 3 years ago by
I believe that there is missing documentation due to #9107 (e.g. any methods in monomial.Element
). This version includes some minor doc changes.
comment:73 in reply to: ↑ 70 Changed 3 years ago by
Replying to zabrocki:
I think the slice defined in
from_symmetric_function
does not preserve the Hopf structure, but the projection preserves both product and coproduct.
If it doesn't preserve the Hopf structure, we can't have it be a coercion (including the w basis to the homogeneous sym funcs). Instead we have to make them all conversions. I'll also add in the natural conversions (ex. the p basis to the powersum sym funcs) on the next update.
Best,
Travis
comment:74 Changed 3 years ago by
from_symmetric_function
is already not a coercion. It is just a method. Are you saying that you don't want to make the map from Sym -> NCSym^{*} a coercion? It preserves the Hopf structure.
For NSym/QSym I believe we have the following:
- NSym -> Sym is a method
to_symmetric_function
- Sym -> QSym is a coercion and can be accessed by
B( sfelement )
whereB
is a basis of QSym - QSym -> Sym under the condition that the element in QSym
is_symmetric
byqsymelement.to_symmetric_function()
or (and this is not preferred)m( qsymelement )
All of these maps preserve the Hopf algebra structure. Similarly for NCSym/NCSym^{*} we have
- NCSym -> Sym is a method
to_symmetric_function
- Sym -> NCSym^{*} is a coercion and can be accessed by
w( sfelement )
- NCSym^{*} -> Sym under the condition that the element in NCSym^{*}
is_symmetric
byncsymdelement.to_symmetric_function()
or (and this is not preferred)h( ncsymdelement )
The maps NCSym -> Sym and NSym -> Sym are not coercions since these maps are projections and hence not invertible. The inclusions of Sym -> NCSym^{*} and Sym -> QSym have an inverse (one sided) and so I think that they can be coercions. I am not too concerned that p( ncsymdelement )
doesn't work. The reason the portal through the h
basis works is because of the connection with the w basis.
comment:75 Changed 3 years ago by
Ah, sorry, I confused myself.
However I coercions do not have to be invertible (ex. ZZ -> QQ
), just are well-defined, preserve the structure, and make commutative diagrams. I think they typically are injections, but this is not a requirement.
The QSym -> Sym
can't be a coercion because it is not well-defined (on all elements). Since NCSym -> Sym
and NSym -> Sym
preserve the Hopf structure and are well-defined. I don't think there's any danger of breaking coercion commutativity. So I think we should make these coercions. Your thoughts?
comment:76 Changed 3 years ago by
I am not comfortable making NCSym
and NSym -> Sym
coercions because when I say that they preserve the Hopf structure I mean that the Hopf structure of NCSym
is mapped onto the Hopf structure of Sym
but NCSym
does not exist as a Hopf subalgebra of Sym
. For Sym -> QSym
it is the case that Sym
exists as a subalgebra of QSym
.
That is, let phi : NCSym -> Sym then sometimes we have, F != G but phi(F) = phi(G) (e.g. F = A*B, G =B*A)
That is, "equalities go to equalities, but sometimes inequalities also go to equalities." (to my eye, not something I want as a coercion). This isn't a hard fast rule, but it seems counter-intuitive to be able to coerce from NCSym to Sym rather than use the method to_symmetric_function
to project onto that space.
For psi: Sym -> NCSym^{*} we have psi(F)=psi(G) iff F=G, that is, "equalities going to equalities and inequalities going to inequalities"
comment:77 Changed 3 years ago by
Since it's consistent with NSym
, I'm fine with NCSym -> Sym
not being a coercion. So what else needs to be done?
comment:78 Changed 3 years ago by
I want to be completely convinced everything works properly and haven't missed any details in the documentation. Give me another day or two to find minor tweaks. Otherwise I am extremely happy with it. Nantel asked just today to use it to compute m_A(x_0,x_1,...,x_n)
and I sent him installation instructions.
comment:79 Changed 3 years ago by
current version moves counit_on_basis
to NCSymOrNCSymDualBases
parent methods and implements antipode_on_basis
in the w parent methods
comment:80 Changed 3 years ago by
Can you check if antipode_on_basis
should be a cached method? I didn't do that, but it computes the antipode using the definition and it is a rather recursive formula.
Changed 3 years ago by
comment:81 Changed 3 years ago by
My tests on the antipode seems to run pretty fast without caching, but please take a look. I just added a new version with some minor doc corrections.
comment:82 Changed 3 years ago by
All tests pass, and documentation looks good. please look over my last version of the patch, fold it with yours, make any last changes, and you have my blessing on a positive review. Nice work!
comment:83 Changed 3 years ago by
A couple of things left to change in the version you posted. Search on SEEALSO because it seems to be duplicated in three places. Also I think that occurrences of \kappa \circ \chi
should be \chi \circ \kappa
.
comment:84 Changed 3 years ago by
- Dependencies changed from #15143, #15164 to #15143, #15164, #10963
- Reviewers set to Mike Zabrocki, Darij Grinberg
Good catch; merge issue. Fixed and same with the map composition order.
Since #10963 is finished (yay), I've added it as a dependency since it seems to affect the output of one of the doctests in bases.py
. Mike, could you double-check to make sure the tests still pass for you? Thanks. And thanks Darij for fixing up the docstrings along the way.
Best,
Travis
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:85 Changed 3 years ago by
Okay, now everything should be squared away wrt the dep on #10963.
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:86 Changed 3 years ago by
- Status changed from needs_review to positive_review
I used sage cloud and git to test this patch. All tests pass (even with #10963 applied). I think that we can be confident that once it has a positive review, that this will pass as well.
comment:87 Changed 3 years ago by
- Milestone changed from sage-5.13 to sage-pending
comment:88 Changed 3 years ago by
yay milestone tug of war!
Is there an easy way to commute this past #10963 or will that make code slower/buggier/whatever?
comment:89 Changed 3 years ago by
- Dependencies changed from #15143, #15164, #10963 to #15143, #15164
- Milestone changed from sage-pending to sage-5.13
Since #10963 is getting pushed back, I've changed the one doctest output to move this past.
For patchbot:
Apply: trac_15150-ncsym-ts.patch
comment:90 Changed 3 years ago by
I cannot promise this will be merged in Sage 5.13 though. Did you test this well, that will increase the chances?
comment:91 Changed 3 years ago by
All tests on the file passed for me on 5.13.beta2
, and once 5.13.beta5
is done compiling, I'll check on that as well.
comment:92 Changed 3 years ago by
Works for me on 5.13.beta5
:
sage -t --long bases.py [148 tests, 14.09 s] sage -t --long dual.py [74 tests, 6.73 s] sage -t --long ncsym.py [197 tests, 26.14 s] sage -t --long set_partition.py [266 tests, 45.62 s] sage -t --long ncsf.py [381 tests, 15.40 s] ---------------------------------------------------------------------- All tests passed! ----------------------------------------------------------------------
And the pdf documentation builds cleanly:
Transcript written on combinat.log. Build finished. The built documents can be found in /home/travis/sage-5.13.beta5/devel/sage/doc/output/pdf/en/reference/combinat
comment:93 Changed 3 years ago by
- Merged in set to sage-5.13.rc0
- Resolution set to fixed
- Status changed from positive_review to closed
[Answered my own question.]