Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not all Verma module morphisms are found #36793

Open
2 tasks done
tscrim opened this issue Dec 1, 2023 · 0 comments
Open
2 tasks done

Not all Verma module morphisms are found #36793

tscrim opened this issue Dec 1, 2023 · 0 comments

Comments

@tscrim
Copy link
Collaborator

tscrim commented Dec 1, 2023

Sage claims that there is no module morphism between these two Verma modules:

sage: L = LieAlgebra(QQ, cartan_type=['A', 2])
sage: La = L.cartan_type().root_system().weight_lattice().fundamental_weights()
sage: M1 = L.verma_module((0*La[1]).dot_action([1]))
sage: M12 = L.verma_module((0*La[1]).dot_action([1,2]))
sage: Hom(M12, M1).dimension()
0

However, there should be one when w \leq v in Bruhat order. Indeed, we can find the singular vector by an explicit computation:

sage: v = M1.highest_weight_vector()
sage: f = L.f()
sage: e = L.e()
sage: f12 = f[1].bracket(f[2])
sage: e[1] * (f[2]*(f[1]*v) + 2*f12*v)
0
sage: e[2] * (f[2]*(f[1]*v) + 2*f12*v)
0

This comes from the fact the current implementation for singular vectors only works with the weights are "strongly linked," or equivalently when they differ by left weak Bruhat order.

The more general algorithm from, e.g., de Graaf's work should be implemented for the singular vectors.

Expected Behavior

This should have dimension 1.

Environment

- **OS**: Ubunutu 20.04
- **Sage Version**: 10.2.rc0

Checklist

  • I have searched the existing issues for a bug report that matches the one I want to file, without success.
  • I have read the documentation and troubleshoot guide
@tscrim tscrim added the t: bug label Dec 1, 2023
vbraun pushed a commit to vbraun/sage that referenced this issue Jul 20, 2024
…ensional Lie algebra representation

    
<!-- ^^^^^
Please provide a concise, informative and self-explanatory title.
Don't put issue numbers in there, do this in the PR body below.
For example, instead of "Fixes sagemath#1234" use "Introduce new method to
calculate 1+1"
-->
<!-- Describe your changes here in detail -->

The goal of this PR is to implement the BGG resolution of a finite
dimensional simple Lie algebra representation $L_{\lambda}$. In order to
implement this, we need to implement a number of features:

- Simple modules (this does not assume finite dimensional).
- Dual modules in BGG category $\mathcal{O}$.
- Fix embeddings of Verma modules sagemath#36793.
- Improve construction of elements of free abelian monoids when strings
are indices.
- Move `to_root_vector()` to a method of fundamental weights and cache
the inverse Cartan matrix.
- Add `is_dominant_weight()` method to weight lattice realization
elements.
- Add `is_verma_dominant()` to define a dominant weight in the sense of
the Humphreys 2008 reference, which means the Verma module is projective
(that is, maximal in its dot action orbit).
- Add the category of `FiniteDimensionalKacMoodyAlgebras`.
- `@cache_in_parent_method` marked `weak_le` for Coxeter groups.
- Subclass of PBW bases for semisimple Lie algebras.

We also add methods to compute the contravariant form of a Verma module
and add tester methods for them being simple or projective.

It is possible to split this up into smaller parts, but it is natural
for them to go together given the final goal.

One major TODO is to speed up the computation of the bases of the simple
modules. The main place to optimize this would be to improve the
multiplication of the PBW basis code, which for finite dimensional Lie
algebras (not necessarily semisimple), this could be improved by using
the fixed basis order and using the monomials as vectors to avoid lots
of calls for getting the sort order and comparing. In particular, the
triangular sorting order for the Chevalley basis implementation has
error messages being raised (and caught) for comparing the roots and
coroots. This will be done at some point on a separate PR.

<!-- Why is this change required? What problem does it solve? -->
<!-- If this PR resolves an open issue, please link to it here. For
example "Fixes sagemath#12345". -->
<!-- If your change requires a documentation PR, please link it
appropriately. -->

### 📝 Checklist

<!-- Put an `x` in all the boxes that apply. -->
<!-- If your change requires a documentation PR, please link it
appropriately -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
<!-- Feel free to remove irrelevant items. -->

- [x] The title is concise, informative, and self-explanatory.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation accordingly.

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on
- sagemath#12345: short description why this is a dependency
- sagemath#34567: ...
-->

<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
    
URL: sagemath#37297
Reported by: Travis Scrimshaw
Reviewer(s): Matthias Köppe, Travis Scrimshaw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants