Implement symplectic and orthogonal bases of Sym

[tscrim]

Following a paper of Chari and Kleber: Symmetric functions and representations of quantum affine algebras, arxiv:0011161v1. We implement the symplectic and orthogonal (filtered) bases of Sym.

Depends on #17096

CC: @sagetrac-sage-combinat @darijgr @simon-king-jena @nthiery

Component: combinatorics

Keywords: days54, sym

Author: Travis Scrimshaw

Branch/Commit: 5b492f3

Reviewer: Mike Zabrocki

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

[tscrim]

comment:1

Darij (or anyone else who wants to review this),

Nicolas said it's fine being in GradedHopfAlgebrasWithBasis since Sym does admit a graded basis, even if the given basis itself is not graded.

[darijgr]

comment:2

I fear Nicolas is wrong here:

sage: o = Sym.o()
sage: TestSuite(o).run()
Failure in _test_antipode:
Traceback (most recent call last):
  File "/home/darij/gitsage/sage-5.13.beta1/local/lib/python2.7/site-packages/sage/misc/sage_unittest.py", line 282, in run
    test_method(tester = tester)
  File "/home/darij/gitsage/sage-5.13.beta1/local/lib/python2.7/site-packages/sage/categories/hopf_algebras_with_basis.py", line 263, in _test_antipode
    tester.assert_(SI(x) == self.counit(x) * self.one())
  File "/home/darij/gitsage/sage-5.13.beta1/local/lib/python/unittest/case.py", line 424, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true
------------------------------------------------------------
The following tests failed: _test_antipode

The problem is that the counit is still defined as the constant coefficient, but that's only true for graded bases. Concrete example:

sage: o[2].counit()
0
sage: s(o[2]).counit()
-1

The same issue would be happening with antipode and degree_negation if not for the fact that the o and sp bases happen to be graded w.r.t. the induced ZZ/2ZZ-grading.

[sagetrac-git]

Changed commit from 9536f54 to 223b11b

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

223b11b	Fix the counit in sp/o bases.
4933218	Merge branch 'develop' into public/combinat/sf/sp_orth

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

9ea2a2c

Added comment about ZZ / 2ZZ grading.

[sagetrac-git]

Changed commit from 223b11b to 9ea2a2c

[tscrim]

comment:5

Replying to @darijgr:

I fear Nicolas is wrong here

...

The problem is that the counit is still defined as the constant coefficient, but that's only true for graded bases.

Yep, but that's technically a fault with the generic symmetric function code, not the category (which I think does it via coercion by default). Fixed.

The same issue would be happening with antipode and degree_negation if not for the fact that the o and sp bases happen to be graded w.r.t. the induced ZZ/2ZZ-grading.

Again, not the category, but it's nice to know these things.

---

New commits:

9ea2a2c

Added comment about ZZ / 2ZZ grading.

[darijgr]

comment:6

I see. Can it be that the SymmetricFunctionsBases class should be split into SymmetricFunctionsBases and SymmetricFunctionsConnectedGradedBases or else we risk running into this whenever other new methods are implemented? If so, I'd suggest doing this (I can do it myself), although I'd wait for #15473 to be merged beforehand.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

fd17c25

Documentation tweaks/typo fixes.

[sagetrac-git]

Changed commit from 9ea2a2c to fd17c25

[tscrim]

comment:8

I doubt there will be too many new methods which a general implementation does not involve coercing to a basis where we can do the computation explicitly, so I don't think it's necessary. Nevertheless, something for another ticket (possibly after a sage-combinat-devel discussion).

[fchapoton]

comment:10

There is a typo "Scirmshaw"

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

de32f11	Merge branch 'public/combinat/sf/sp_orth' of trac.sagemath.org:sage into public/combinat/sf/sp_orth
db8a17c	Learning to spell my name...

[sagetrac-git]

Changed commit from fd17c25 to db8a17c

[tscrim]

comment:12

XP

[sagetrac-git]

Changed commit from db8a17c to 523c023

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

523c023

Merge branch 'public/combinat/sf/sp_orth' of trac.sagemath.org:sage into public/combinat/sf/sp_orth

[nathanncohen]

comment:16

Please do not use abbreviations like "lps" in the name of functions.

Nathann

[tscrim]

comment:45

However, I don't think that is the right solution. :/ The check is reasonable and necessary.

Granted, my current proposal is a major hack, but I don't think too many people will be creating many instances of Sym over various large finite fields (and there are more computationally intensive parts necessary for working with Sym). I'm tired of trying to deal with this here, so I just checked if the base ring was a field before any categories get created.

There is also another issue with C3 in that I get a KeyError if I make this change:

         cat = HopfAlgebras(self.base().base_ring())
         return [self.base().Realizations(),
                 cat.Commutative().WithBasis(),
-                cat.Graded().Realizations()]
+                cat.Commutative().Graded().Realizations()]

This is what it should be, but because everything commutative will come from the cat.Commutative().WithBasis(), I think we are okay for now.

I really would like to push this ticket in and later reach in and fix the category-refinement/MRO/C3 issues on a separate ticket.

---

New commits:

8263b10	Merge branch 'develop' into public/combinat/sf/sp_orth
b151195	Merge branch 'develop' into public/combinat/sf/sp_orth
8e690e2	Some hacks and FIXMEs.

[tscrim]

comment:46

I should also mention that there are other places where category refinement would make sense, such as for finite-dimensional algebras after doing an is_commutative or is_unital test, so IMO it could be useful beyond prime testing for finite fields.

[zabrocki]

comment:47

What does the line "R in Fields()" do? It looks to me like it returns True or False and goes on to the next line.

[tscrim]

comment:48

It makes sure that R has had its category refined (if it needs to). Thus this is not done in the process of building the MRO/category heirarchy for Sym.

[zabrocki]

comment:49

I don't think that this is a bad way of resolving this, but it may be pushing the problem elsewhere. I am seeing:

File "combinat/ncsf_qsym/qsym.py", line 1873, in sage.combinat.ncsf_qsym.qsym.QuasiSymmetricFunctions.Monomial.lambda_of_monomial
Failed example:
    M = QuasiSymmetricFunctions(Integers(5)).Monomial()

Are ncsf/qsym going to require the same hack? Will every combinatorial Hopf algebra require it?

[tscrim]

comment:50

I've not been getting those errors, but Volker just posted on #19397 an issue that smells like the same thing. So right now I'm thinking, "*!@$, we have to deal with this now". :/ Nicolas, Simon, I will need you two to get involved now I think.

[zabrocki]

comment:51

One strange feature is that the error that you post in comment 40 is triggered on QSym and NCSymD but not on NCSF or NCSym (at least on my computer). That is,

sage: NCSymD = SymmetricFunctionsNonCommutingVariablesDual(FiniteField(23))
sage: NCSymD = SymmetricFunctionsNonCommutingVariablesDual(Integers(23))

triggers an error but

sage: NCSym = SymmetricFunctionsNonCommutingVariables(FiniteField(23))
sage: NCSym = SymmetricFunctionsNonCommutingVariables(Integers(23))

does not.

[tscrim]

comment:52

The NCSymD is caused by this part of the __init__:

        Sym = SymmetricFunctions(self.base_ring())
        Sym_h_to_w = Sym.h().module_morphism(w.sum_of_partitions,
                                             triangular='lower',
                                             inverse_on_support=w._set_par_to_par,
                                             codomain=w, category=category)

Ah...QSym fails for the same reason...

I think they all will need this hack for now. I know this is pushing the problem further down, but I don't know of a way to resolve it at present (or at least without forcing a prime check for finite rings).

Although there is the issue on comment:45 that is likely unrelated and needs a fix at some point too... I think there might be some issue(s) with join categories...

I also have been working on #19397 under the assumption that these are the same problem. However I am pretty sure this is not the case now and they are different problems (I would love to be wrong).

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

d8d3eda

additions to NCSF/QSym/Sym/NCSym/NCSymD to ensure that MRO errors are not triggered

[sagetrac-git]

Changed commit from 8e690e2 to d8d3eda

[zabrocki]

comment:54

I agree. In the end this is a minor change as a hack. It doesn't locate the problem, but it does fix it from being triggered. I've pushed some changes which add doctests and replaced assert(R in Rings()) with assert(R in Fields() or R in Rings()) in in the __init__ method for all of these Hopf algebras. I'll get back to Jean-Baptist's Hopf algebra implementations after we resolve these issues and see if his code can be used to get around these problem.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

c4c1416	Merge branch 'develop' into public/combinat/sf/sp_orth
0513f6a	Merge branch 'public/combinat/sf/sp_orth' of trac.sagemath.org:sage into public/combinat/sf/sp_orth
5b492f3	Fixing non-ascii character.

[sagetrac-git]

Changed commit from d8d3eda to 5b492f3

[tscrim]

comment:56

I'm okay with things. So let's just leave this hack in there since it works for now. It is also documented for testing later on. Therefore I think we are back to needs review.

[zabrocki]

comment:57

I think it looks good and all tests pass. Positive review.

[zabrocki]

Reviewer: Mike Zabrocki

[tscrim]

comment:58

Thanks Mike!

[vbraun]

Changed branch from public/combinat/sf/sp_orth to 5b492f3