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

Attachments (5)

trac_15150_product_on_basis_q-mz.patch (3.4 KB) - added by zabrocki 4 years ago.
trac_15150-docs-dg.patch (15.0 KB) - added by darij 4 years ago.
not a review but a few improvement suggestions (docstrings mostly)
trac_15150-duality_pairing-mz.patch (5.8 KB) - added by zabrocki 4 years ago.
trac_15150-docchanges-mz.patch (16.0 KB) - added by zabrocki 3 years ago.
trac_15150-ncsym-ts.patch (125.4 KB) - added by tscrim 3 years ago.
with fixes

Download all attachments as: .zip

Change History (98)

comment:1 Changed 4 years ago by saliola

[Answered my own question.]

Last edited 4 years ago by saliola (previous) (diff)

comment:2 Changed 4 years ago by tscrim

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.

Last edited 4 years ago by tscrim (previous) (diff)

comment:3 Changed 4 years ago by saliola

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 darij

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 tscrim

  • 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 tscrim

  • Description modified (diff)

Also I just fixed the w basis multiplication.

comment:7 Changed 4 years ago by tscrim

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

comment:8 Changed 4 years ago by zabrocki

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 tscrim

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 zabrocki

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 tscrim

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 zabrocki

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 tscrim

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 zabrocki

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 tscrim

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.

Last edited 4 years ago by tscrim (previous) (diff)

comment:16 Changed 4 years ago by tscrim

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 zabrocki

comment:17 Changed 4 years ago by zabrocki

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 zabrocki

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.

Last edited 4 years ago by zabrocki (previous) (diff)

comment:19 Changed 4 years ago by darij

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 tscrim

  • 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​

Last edited 4 years ago by tscrim (previous) (diff)

comment:21 Changed 4 years ago by zabrocki

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

comment:22 Changed 4 years ago by tscrim

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​

Last edited 4 years ago by tscrim (previous) (diff)

comment:23 follow-up: Changed 4 years ago by 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.

comment:24 in reply to: ↑ 23 Changed 4 years ago by tscrim

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​

comment:25 Changed 4 years ago by zabrocki

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 chapoton

for the patchbots:

apply only trac_15150-ncsym-ts.patch​

comment:27 Changed 4 years ago by chapoton

for the patchbots:

apply only trac_15150-ncsym-ts.patch​

comment:28 Changed 4 years ago by chapoton

Patchbots are dummy ?

apply trac_15150-ncsym-ts.patch

comment:29 Changed 4 years ago by darij

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

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

comment:31 Changed 4 years ago by darij

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 darij

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]
Last edited 4 years ago by darij (previous) (diff)

comment:33 Changed 4 years ago by tscrim

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 darij

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 tscrim

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 chapoton

  • Status changed from needs_review to needs_work

many failing doctests

comment:37 Changed 4 years ago by tscrim

  • Status changed from needs_work to needs_review

Now with fixed doctests.

comment:38 Changed 4 years ago by zabrocki

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?

Last edited 4 years ago by zabrocki (previous) (diff)

comment:39 Changed 4 years ago by tscrim

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 4 years ago by zabrocki

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 4 years ago by darij

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 4 years ago by tscrim

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

Changed 4 years ago by darij

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

comment:43 Changed 4 years ago by tscrim

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

Last edited 4 years ago by tscrim (previous) (diff)

comment:44 Changed 4 years ago by darij

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 4 years ago by tscrim

Whoops. Fixed.

Apply: trac_15150-ncsym-ts.patch

comment:46 Changed 4 years ago by darij

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.

Last edited 4 years ago by darij (previous) (diff)

comment:47 follow-up: Changed 4 years ago by tscrim

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 4 years ago by zabrocki

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 4 years ago by zabrocki

comment:49 Changed 4 years ago by tscrim

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 4 years ago by zabrocki

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 4 years ago by tscrim

Hey Mike.

Yes. It is more about it being a section of the natural projection and working with the map with NSym.

Last edited 4 years ago by tscrim (previous) (diff)

comment:52 Changed 4 years ago by zabrocki

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 4 years ago by zabrocki

more doc changes

comment:54 Changed 4 years ago by tscrim

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 4 years ago by zabrocki

  • Dependencies changed from #15143 to #15143, #15164

comment:56 Changed 4 years ago by zabrocki

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 4 years ago by zabrocki

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 4 years ago by darij

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

Last edited 4 years ago by darij (previous) (diff)

comment:59 Changed 3 years ago by zabrocki

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 darij

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 tscrim

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 zabrocki

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 tscrim

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 tscrim

Okay, fixed. They all return ValueErrors now and I'm now using the ordering on lambda_i in the method.

comment:65 Changed 3 years ago by zabrocki

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 zabrocki

A few minor changes in whitespace and pyflakes warnings.

comment:67 Changed 3 years ago by darij

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 zabrocki

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]
Last edited 3 years ago by zabrocki (previous) (diff)

comment:69 Changed 3 years ago by darij

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: Changed 3 years ago by zabrocki

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 zabrocki

I added a few doc tests that hopefully clarifies the purpose of from_symmetric_function.

comment:72 Changed 3 years ago by zabrocki

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 tscrim

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 zabrocki

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 ) where B is a basis of QSym
  • QSym -> Sym under the condition that the element in QSym is_symmetric by qsymelement.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 by ncsymdelement.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 tscrim

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 zabrocki

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 tscrim

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 zabrocki

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.

Last edited 3 years ago by zabrocki (previous) (diff)

comment:79 Changed 3 years ago by zabrocki

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 zabrocki

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 zabrocki

comment:81 Changed 3 years ago by zabrocki

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 zabrocki

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 zabrocki

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 tscrim

  • 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 tscrim

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 zabrocki

  • 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 jdemeyer

  • Milestone changed from sage-5.13 to sage-pending

comment:88 Changed 3 years ago by darij

yay milestone tug of war!

Is there an easy way to commute this past #10963 or will that make code slower/buggier/whatever?

Last edited 3 years ago by darij (previous) (diff)

Changed 3 years ago by tscrim

with fixes

comment:89 Changed 3 years ago by tscrim

  • 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 jdemeyer

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 tscrim

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 tscrim

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 jdemeyer

  • Merged in set to sage-5.13.rc0
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.