#15164: NSym (NCSF): Verschiebung, doc improvements, meet and join of
compositions
-------------------------------------------------+-------------------------
Reporter: darij | Owner:
Type: enhancement | Status:
Priority: major | needs_review
Component: combinatorics | Milestone: sage-5.12
Keywords: sage-combinat, NSym, NCSF, | Resolution:
symmetric functions | Merged in:
Authors: Darij Grinberg | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: #14775, #14981, #15094, | Stopgaps:
#15122 |
-------------------------------------------------+-------------------------
Description changed by darij:
Old description:
> 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.
>
> 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?
New description:
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.
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
anything.
* 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#comment:3>
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.
