#15205: NSym (NCSF): bugs or weird design decisions
-------------------------------------------------+-------------------------
Reporter: darij | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-5.13
Component: combinatorics | Resolution:
Keywords: sage-combinat, NSym, NCSF, | Merged in:
Sym, symmetric-functions | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: #15164 |
-------------------------------------------------+-------------------------
Description changed by darij:
Old description:
> Here are the issues that haven't been deal with in #15164:
>
> * I don't understand why the internal product is implemented in
> {{{ncsf_qsym/generic_basis_code.py}}} rather than
> {{{ncsf_qsym/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 understand it is implemented in some weirdly curried form,
> but then its target should be a Hom space.
>
> * I was 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? If this can be
> explained, I'll implement the verschiebung on a few more bases (Psi and
> Phi both have very simple formulas).
New description:
Here are the issues that haven't been deal with in #15164:
* I don't understand why the internal product is implemented in
{{{ncsf_qsym/generic_basis_code.py}}} rather than {{{ncsf_qsym/ncsf.py}}}.
Isn't {{{generic_basis_code.py}}} for methods shared between QSym and
NSym? There is no internal product on QSym.
[*Update:* This is not a real issue. The code isn't in the wrong class,
it's just in a slightly unexpected module.]
* 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 understand it is implemented in some weirdly curried form, but
then its target should be a Hom space.
[*Update:* From a conversation with Travis, this is wrong, but probably
not worth fixing at the current stage.]
* I was 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? If this can be explained, I'll
implement the verschiebung on a few more bases (Psi and Phi both have very
simple formulas).
[*Update:* It should be `class Element(CombinatorialFreeModule.Element):`
rather than `class ElementMethods:`. At least verschiebung works now. I'll
post that patch soon; right now an unrelated bug has to be fixed first.]
--
--
Ticket URL: <http://trac.sagemath.org/ticket/15205#comment:2>
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.
