#6588: Categories for root systems
--------------------------------------------------------+-------------------
Reporter: nthiery | Owner:
mhansen
Type: enhancement | Status:
needs_review
Priority: major | Milestone:
sage-5.0
Component: combinatorics | Keywords: root
systems, categories
Work_issues: | Upstream: N/A
Reviewer: Anne Schilling, Mark Shimozono, PatchBot | Author:
Nicolas M. Thiéry
Merged: | Dependencies:
#10817
--------------------------------------------------------+-------------------
Comment(by aschilling):
Replying to [comment:12 nthiery]:
> Thanks much Anne for your detailed review!
You are welcome. I hope you will return the favor for trac_12536
-linear_extensions-as.patch!
> > - Why is the cateogry RootLatticeRealization in
> > /sage/combinat/root_system/root_lattice_realization.py
> > here and not in categories (if it is a category as specified in the
docstring)?
> >
> > The same question holds for
WeightLatticeRealizations(Category_over_base_ring)
> > in /sage/combinat/root_system/weight_lattice_realization.py.
>
> Yeah, we had a similar discussion for the crystal categories and the
> categories for Symmetric Functions and friends. And there is a non
> trivial borderline to set.
>
> On one hand, we have general categories (like Groups, Algebras, ...)
> which are likely to get used in several Sage modules. Also, they name
> a well-known area of mathematics; so it's natural to import them by
> default in the interpreter, if not just as an entry point.
>
> On the other hand we have categories that are rather specific to a
> Sage module, if not just implementation details. So it's good to keep
> them in this module, in particular to be as close as close as possible
> from the other sources of that module.
>
> CoxeterGroups clearly fits the first case (most mathematicians have
> heard of them; this category is used by WeylGroup (in
> sage.combinat.root_system) and by SymmetricGroup (in sage.groups).
>
> The categories for symmetric functions are basically implementation
> details and fits in the second case. Anyway, SymmetricFunctions is
> already a good entry point.
>
> Crystals are only implemented in sage.combinat.crystals (so far). But
> this names an area of mathematics. So this fits a bit more the first
> case.
No, there is a lot of crystal code in /sage/categories: crystals,
finite_crystals, highest_weight_crystals, ....
> > - When using the extended weight lattice, the list of fundamental
weights
> > does not include `\delta`. On the other hand it is possible to input
> > `\delta` into the method fundamental_weight. This seems a little
> > inconsistent.
>
> Yeah, this abuse is documented in "fundamental_weight". Basically, we
> need a function that describes the embedding of the basis elements of
> the (extended) weight lattice. That's almost what fundamental_weight
> does, and I did not have a good alternative name. So I abused
> fundamental_weight to do just a bit more that its natural job.
> Anyway, we currently only have a single implementation of
> WeightLatticeRealizations in the affine case, so it's very localized,
> and easy to change in the future if we come up with a good name
> (unless you have one!).
Why can't fundamental_weights when "extended" is set also include `delta`?
This would at least fit with the notational abuse of fundamental_weight.
> Let me know if you are ok with the above and with my reviewer's patch.
> If yes, I'll fold the patches, reindent properly
> root_lattice_realization.py and weight_lattice_realization.py, and add
> a 's' at the end of those files (I haven't done those yet to keep the
> diff meaningful). Then, the patch will be good to go.
I also wrote another very small reviewer's patch that you can fold in.
> For the record, all tests pass on Sage 5.0 beta6, with the following
> patches applied:
> {{{
> trac_10817-generalized_associahedra-cs.patch
> trac_12645-fix_rst_markup-sk.patch
> trac_9128-intersphinx_python_database-fh.patch
> trac_9128-sphinx_links_all-fh.patch
> trac_9128-MANIFEST-fh.patch
> trac_12527-fraction_field-is_exact_optimization-nt.patch
> trac_12510-nonzero_equal_consistency-fh.patch
> trac_12536-linear_extensions-as.patch
> element_compare_consistency-fh.patch
> trac_11880-isgci-all_in_one-nc.patch
> trac_11880-isgci-more-review-nt.patch
> trac_7980-multiple-realizations-nt.patch
> trac_7980-multiple-realizations-review-nt.patch
> trac_6588-categories-root_systems-nt.patch
> trac_6588-categories-root_systems-review-nt.patch
> }}}
That's good!
Cheers,
Anne
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6588#comment:16>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
