Implement NCSym

[tscrim]

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: attachment: trac_15150-ncsym-ts.patch​

Depends on #15143 Depends on #15164

CC: @sagetrac-sage-combinat @zabrocki @saliola @darijgr

Component: combinatorics

Author: Travis Scrimshaw

Reviewer: Mike Zabrocki, Darij Grinberg

Merged: sage-5.13.rc0

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

[saliola]

comment:1

[Answered my own question.]

[tscrim]

comment:2

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.

[saliola]

comment:3

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!

[darijgr]

comment:4

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.

[tscrim]

comment:5

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.

[tscrim]

Description changed:

--- 
+++ 
@@ -1,11 +1,11 @@
 Implement the Hopf algebra of symmetric functions in non-commuting variables in the following bases:

-- monomial
-- elementary
-- homogeneous
-- power-sum
-- x
-- q
+- monomial **m**
+- elementary **e**
+- homogeneous **h**
+- power-sum **p**
+- **x**
+- **q**

-as well as the dual basis w.
+as well as the dual basis **w**.

[tscrim]

comment:6

Also I just fixed the w basis multiplication.

[tscrim]

comment:7

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 creating SymmetricFunctionNonCommutingVariables in order to set up the coercion.
• Is it safe to put the natural maps Sym -> NCSym and NSym -> NCSym as coercions?

The references I used are included in the documentation now too.

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:8

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.

[tscrim]

comment:9

New version rebased over changes in #15143 and removes the word "natural" and instead states that it is the map which fixes Sym.

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:10

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.

[tscrim]

comment:11

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

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:12

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}}

[tscrim]

comment:13

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?

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:14

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?

[tscrim]

comment:15

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.

[tscrim]

comment:16

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.

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:17

Attachment: trac_15150_product_on_basis_q-mz.patch.gz

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.

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:18

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.

[darijgr]

comment:19

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.

[tscrim]

comment:20

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​

[tscrim]

Description changed:

--- 
+++ 
@@ -9,3 +9,4 @@

 as well as the dual basis **w**.

+Apply: [attachment: trac_15150-ncsym-ts.patch​](https://github.com/sagemath/sage/files/ticket15150/4c8b34f12e835d39d5e45bdc50893444.gz)

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:21

Hi Travis, Is it possible that this is the same patch as before?

[tscrim]

comment:22

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​

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:23

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.

[tscrim]

comment:24

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

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​

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:25

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.

[fchapoton]

comment:26

for the patchbots:

apply only trac_15150-ncsym-ts.patch​

[fchapoton]

comment:27

for the patchbots:

apply only trac_15150-ncsym-ts.patch​

[fchapoton]

comment:28

Patchbots are dummy ?

apply trac_15150-ncsym-ts.patch

[darijgr]

comment:29

"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}

[tscrim]

comment:30

Try it with SetPartitions(3, [2,1,1]).

[darijgr]

comment:31

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: 

[darijgr]

comment:32

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]

[tscrim]

comment:33

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

[darijgr]

comment:34

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.

[tscrim]

comment:35

Hey Mike,

I've added an is_symmetric() method to the w basis.

For patchbot:

Apply: trac_15150-ncsym-ts.patch

[fchapoton]

comment:36

many failing doctests

[tscrim]

comment:37

Now with fixed doctests.

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:38

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?

[tscrim]

comment:39

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

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:40

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.

[darijgr]

comment:41

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?

[tscrim]

comment:42

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

[darijgr]

not a review but a few improvement suggestions (docstrings mostly)

[tscrim]

comment:43

Attachment: trac_15150-docs-dg.patch.gz

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

[darijgr]

comment:44

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

[tscrim]

comment:45

Whoops. Fixed.

Apply: trac_15150-ncsym-ts.patch

[darijgr]

comment:46

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.

[tscrim]

comment:47

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