#15164: NSym (NCSF): Verschiebung, doc improvements, meet and join of
compositions
-------------------------+-------------------------------------------------
Reporter: darij | Owner:
Type: | Status: new
enhancement | Milestone: sage-5.12
Priority: major | Keywords: sage-combinat, NSym, NCSF,
Component: | symmetric functions
combinatorics | Authors: Darij Grinberg
Merged in: | Report Upstream: N/A
Reviewers: | Branch:
Work issues: | Dependencies: #14775, #14981, #15094,
Commit: | #15122
Stopgaps: |
-------------------------+-------------------------------------------------
This patch does the following:
* Implement the Verschiebung map on NSym (the map adjoint to the Frobenius
on QSym implemented in #15094). The current implementation handles all
bases by coercion to the homogeneous one. I planned to implement the Psi,
Phi, R and L bases separately, but I am unable to (see below).
* Add a {{{to_descent_algebra}}} map to the newly implemented (#14981)
descent algebra. The difference between the signature of my map,
{{{to_descent_algebra(self, n)}}}, and that of the old map to the
symmetric group algebra, {{{to_symmetric_group_algebra(self)}}}, is
intentional: My map takes a noncommutative symmetric function {{{self}}}
and an integer {{{n}}} and projects the {{{n}}}-th homogeneous component
of {{{self}}} on the {{{n}}}-th descent algebra; the map
{{{to_symmetric_group_algebra}}} takes just a noncommutative symmetric
function {{{self}}} and projects it on the {{{deg(self)}}}-th symmetric
group algebra if {{{self}}} is homogeneous, otherwise throws an exception.
If {{{self}}} is 0, then it outputs the int 0 (because 0 doesn't have a
degree). In my opinion, my signature is the better one, not least because
it handles 0 correctly.
* Clean up some of the doc and add definitions for the most important
bases. The inaptly named "MultiplicativeBasesOnGroupLikeElements" class
now has a more explanatory docstring. The incorrect claim about
m_to_s_stat always outputting an integer has been removed. Dependency on
the base ring being a QQ-algebra has been made clearer.
* The meet and the join of two compositions wrt the refinement order have
been implemented (as a sort of continuation of #15122, which is a
dependency).
Here are things I wanted to change/add but got too confused:
* I don't understand why the internal product is implemented in
{{{generic_basis_code.py}}} rather than {{{ncsf.py}}}. Isn't
{{{generic_basis_code.py}}} for methods shared between QSym and NSym?
There is no internal product on QSym.
* This here is a doctest which has been around before me:
{{{
sage: N = NonCommutativeSymmetricFunctions(QQ)
sage: S = N.complete()
sage: S.internal_product
Generic endomorphism of Non-Commutative Symmetric
Functions over the Rational Field in the Complete basis
}}}
The output makes no sense: The internal product is not an endomorphism of
everything.
* I am trying to overshadow the {{{verschiebung}}} function I implemented
on a generic NSym basis by a specific implementation on the ribbon basis.
So I've added it under {{{class ElementMethods:}}} in the {{{class
Ribbon}}}. But it doesn't get precedence over the generic implementation
at runtime! What am I doing wrong?
* This is probably for Travis: is it intentional that the
{{{to_symmetric_group_algebra}}} method in {{{descent_algebra.py}}} is
defined only on the D-basis, rather than on every basis or globally on the
whole descent algebra?
--
Ticket URL: <http://trac.sagemath.org/ticket/15164>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
