-
Notifications
You must be signed in to change notification settings - Fork 134
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
Kashiwara crystals and Littelmann path model #4031
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some random things I noticed while looking through this.
@@ -130,10 +133,14 @@ export coxeter_matrix | |||
export derived_algebra | |||
export dim_of_simple_module | |||
export dominant_character | |||
export dominant_path | |||
export ealpha, ealpha! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think these names are particularly readable. What about something like e_alpha
or maybe e_operator
?
|
||
# AbstractCrystalElem required methods | ||
|
||
function Base.eps(b::AbstractCrystalElem) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please don't overload the julia base function that gives you the machine precision
end | ||
|
||
@doc raw""" | ||
Apply the root operator $\tilde e_i$ to `b` in place and return the result. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apply the root operator $\tilde e_i$ to `b` in place and return the result. | |
ealpha!(b::AbstractCrystalElem, i::Int) | |
Apply the root operator $\tilde e_i$ to `b` in place and return the result. |
This and the next few docstrings are indented weirdly
# AbstractCrystal optional methods | ||
|
||
@doc raw""" | ||
is_upper_normal(B::AbstractCrystal) -> bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is_upper_normal(B::AbstractCrystal) -> bool | |
is_upper_normal(B::AbstractCrystal) -> Bool |
types in julia are uppercase (more similar places below)
@doc raw""" | ||
ealpha(b::AbstractCrystalElem, i::Vector{Int}, n::Vector{Int}) -> AbstractCrystalElem | ||
|
||
Return the result of applying the root operator $\tilde e_i$ to `b`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
n
is missing from the docstring
return s | ||
end | ||
|
||
# LS Path Model |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe split up the file into 1. abstract crystal stuff and 2. path models?
Maybe @fingolfin or @ulthiel have some opinion on how to name the abstract crystal functions (see initial comment by felix), or can ping some people that might want to take part in this? |
I have no idea at all what a "Kashiwara crystal" is, or an "abstract crystal". After some quick googling it doesn't seem to have any obvious connection to "usual" crystals such as studied in chemistry, and for which crystallographic groups are made, so I don't feel qualified to comment. |
Maybe this is a good reason to not call this Edit: There are also crystals in connection with crystalline cohomology. |
@@ -0,0 +1,19 @@ | |||
# Crystals | |||
|
|||
According to Kashiwara a crystal is a set $B$ together with the following maps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are "the following maps" ?
|
||
According to Kashiwara a crystal is a set $B$ together with the following maps | ||
|
||
This is realised in OSCAR through the `AbstractCrystal` and `AbstractCrystalElem` interfaces and the following methods |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence should end with a period or colon.
weight(::AbstractCrystalElem) | ||
``` | ||
|
||
Additionally the following methods are provided |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence should end with a period or colon.
|
||
export AbstractCrystal, AbstractCrystalElem |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
off-topic question for @lgoettgens: these export
statements all have to be duplicate. Would it make sense to put them into an exports.jl
and then just include
that twice, in both locations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great idea. I just checked, and the two lists (already on current master), differ by some things (some names get exported just into the Oscar namespace but not exported from Oscar, and thus make it easier for other devs to use them and thus work against #3408 by accident). I'll prepare a PR for streamlining the two lists and putting them somewhere separate. This PR can then get rebased afterwards.
@doc raw""" | ||
is_upper_normal(B::AbstractCrystal) -> bool | ||
|
||
Return `true` if `B` is upper normal, and `false` if `B` is not upper normal or it is unknown. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a standard term, that everyone working on these things would immediately understand? If not perhaps it could be briefly defined here?
Alternatively resp. in addition, a reference should be added to the bibliography that defines all these terms, and your .md
file should point out this reference: "We follow the terminology and definitions in CITE".
@doc raw""" | ||
ealpha(b::AbstractCrystalElem, i::Int, n::Int) -> AbstractCrystalElem | ||
|
||
Return the result of applying the root operator $\tilde e_i$ to `b` `n`-times. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend to avoid putting formulas directly adjacent. How about this (and of course similarly in other places that do this):
Return the result of applying the root operator $\tilde e_i$ to `b` `n`-times. | |
Return the result of `n`-times applying the root operator $\tilde e_i$ to `b`. |
(There is probably a more elegant way to phrase this, perhaps our native speakers @JohnAAbbott or @mjrodgers have a suggestion)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the original is good, but without the hyphen:
Return the result of applying the root operator to b
n
times.
Or alternately
Applies the root operator to b
n
times.
Applies the root operator n
times to b
.
Edit: Looks better maybe with the b
and n
separated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly: result of n
-fold application of the root operator to b
.
For readability we do need to keep b
and n
separated (by more than just a space).
|
||
# other | ||
|
||
function adapted_string(p::AbstractCrystalElem, rdec::Vector{Int}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is undocumented, and so looks like an internal helper. So why is it exported?
|
||
# LS Path Model | ||
|
||
struct LSPathModel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a docstring
w::WeylGroupElem | ||
end | ||
|
||
function Base.:(==)(s1::LSPathSegment, s2::LSPathSegment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When defining a custom ==
method, make sure to also (two argument) hash
method if there is even a tiny chance of anyone ever trying to use these as keys in a dictionary or apply unique
to them etc.
Seems you have one for LSPathModelElem
, but not for LSPathSegment
; and the former ends up hashing elements of the latter type, so I guess you really need this.
rk = rank(root_system(parent(iter.el))) | ||
if isempty(word) | ||
return nothing | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rk = rank(root_system(parent(iter.el))) | |
if isempty(word) | |
return nothing | |
end | |
isempty(word) && return nothing | |
rk = rank(root_system(parent(iter.el))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rk = rank(root_system(parent(iter.el))) | |
if isempty(word) | |
return nothing | |
end | |
rk = rank(root_system(parent(iter.el))) |
#4030 is merged now
There is a difference between a Kashiwara crystal and an (abstract) crystal in the sense of Kashiwara, where the first one is a very specific crystal and the second came from abstracting the first. That's why naming it For the same reason naming |
1ebb681
to
a21e7de
Compare
2569509
to
6ecb671
Compare
I am currently working on realizing the LS path model in OSCAR. The main goal is to replicate and extend the functionality currently provided in the QuaGroup package, while making it more convenient to use.
Since the path model is a Kashiwara crystal, I also want to provide an abstract type
AbstractCrystal
, since many things can be defined using only the abstract structure. Finding proper names for the functions proves rather difficult, since they have no explicit names in literature, so I would like to gather some suggestions.Currently I have the following:
ealpha(b::AbstractCrystalElem, i::Int), falpha(b::AbstractCrystalElem, i::Int)
. The naming here was taken from the QuaGroup package, since I couldn't find anything better.eps(b::AbstractCrystalElem, i::Int), phi(b::AbstractCrystalElem, i::Int)
. Sinceeps
already existed I hijacked it, not very happy with current names.weight(b::AbstractCrystalElem)