#15463: Implement crystal morphisms, subcrystals, and virtual crystals
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.0
Component: combinatorics | Resolution:
Keywords: crystals, | Merged in:
morphisms, subcrystals | Reviewers:
Authors: Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | 5ee50cd5c9b2d8f6aa2d0fbced80c154f1884f25
public/combinat/crystals/crystal_morphisms| Stopgaps:
Dependencies: #15462 |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:5 nthiery]:
> Replying to [comment:2 tscrim]:
> > Also, I'd like to deprecate the method `crystal_morphism` in place of
`morphism`,
>
> I am not sure to have all elements of context for the case at hand, but
the name ``crystal_morphism`` is a priori better than ``morphim``. For the
same reason, we have module_morphism, algebra_morphism etc else where. The
point is that if a set has several structures this naming convention
avoids conflicts.
What would you recommend doing? The output/behavior of the method would
radically change, but is that okay? Then should we then move the old
functionality into KR crystals to avoid rewriting the promotion
functionality there? Thanks.
--
Ticket URL: <http://trac.sagemath.org/ticket/15463#comment:7>
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.
