These indeed are the marks or labels in Kac' tables Aff1 and Aff2. We can
do the following:
sage: ct = CartanType(['E',6,2])sage:
L=RootSystem(ct).weight_lattice(extended=True)
sage: a = ct.a(); sum(a[i]*L.simple_root(i) for i in L.index_set())
delta
This produces delta for every Cartan Type
All of this is very helpful, thanks Travis, Anne and Nicolas.
Another thing that is needed is the invariant inner product on the weight
space.
Kac gives it explicitly with respect to the basis
alpha_0, alpha_1, ... , alpha_n, Lambda_0. To get it with respect to the
basis Lambda_0, ... ,
Would it do to coerce the two elements to the (affine extended)
ambient space, and use the inner product there? If speed is an issue,
one could cache the result on the bases.
Is the invariant inner product implemented already in the ambient space?
I think what is called inner product is
In the Cartan type documentation (cartan_type.py) we find the following
statement:
The direction of the arrows is the **opposite** (i.e. the
transpose)
Perhaps we should just say that Bourbaki's Cartan matrix is the transpose of
Kac's
and that we follow Kac, omitting reference to the Dynkin diagram at this
point, or
else state (here or elsewhere) that in every convention the arrow points
from the
long root to the short root. I could include a
it must be nontrivial
when the Dynkin diagram has no automorphism. But if there is a nontrivial
automorphism, the permutation might or might not be trivial:
Dne pondělí, 30. prosince 2013 20:11:16 UTC+1 bump napsal(a):
If G is a Lie group and H is a maximal subgroup, the branching rule G=H
We were trying to find FQSym in sage-git. We tried checking out the branch
u/elixyre/ticket/13793 but did not find the code we are looking for. We were
hoping to find code for FreeQuasiSymmetricFunctions similar to this:
https://bitbucket.org/nborie/cha
Did we check out the wrong branch?
On
If G is a Lie group and H is a maximal subgroup, the branching rule G=H is
the
rule describing how irreducible representations of G decompose into
irreducibles
of H. These are implemented in Sage as methods of the WeylCharacterRing,
but until recently there were a few gaps in the built-in rules.
/TentativeConventions) I used the command:
$ git push --set-upstream origin
15361-branching-rules:remotes/origin/public/combinat/15361-branching-rules
remote: FATAL: W
refs/heads/remotes/origin/public/combinat/15361-branching-rules sage bump
DENIED by fallthru
remote: error: hook declined to update
refs
Thank you for making the list. I am a little worried that this might
actually
not catch all dependencies. For example trac_14847-whittaker.patch
definitely
depends on the functionality of trac_14102-nonsymmetric-macdonald.patch
even though
they do not touch the same files.
And
Some code that would produce weight diagrams was in this ticket:
http://trac.sagemath.org/sage_trac/ticket/10744
The final version of this patch by Benjamin Jones gave pretty good weight
diagrams.
It was never merged but maybe it should be revived. This is very
desirable functionality. Of course,
In sage-5.5.beta0 some stuff was merged that is supposed to speed
up WeylCharacterRing, but I noticed the following taking forever now:
sage: A3 = WeylCharacterRing('A3', style='coroots')
sage: A3 = WeylCharacterRing('A3', style='coroots')
One of these should be A4.
sage:
On Monday, October 8, 2012 4:50:58 AM UTC-7, Volker Braun wrote:
If you click on log then you see that the server timed out. This was
sometime last week where the patchbot server was down. You can re-run the
tests by adding ?kick to the url (I just did that, for the record)
Can anyone explain to me why the tracbot gives a red light
to #13461?
The link gives the message apply failed, but the patch
applies cleanly to sage-5.4.rc0. Moreover, the log doesn't
show any hunks that failed to apply, unlike other cases
where the patch didn't apply.
On 10/7/12 4:53 PM, Daniel Bump wrote:
Can anyone explain to me why the tracbot gives a red light
to #13461?
The link gives the message apply failed, but the patch
applies cleanly to sage-5.4.rc0. Moreover, the log doesn't
show any hunks that failed to apply, unlike other
Dan: in the code for the WeylCharacterRing, do you foresee any piece
of code that would not work generically for any realization of the
weight lattice?
Not in principle, but anyway I think the immediate request
can be satisfied in the context of #13461 (see my previous
in this thread).
By
As I noted in my previous message, #13461 implements Demazure characters
in WeylCharacterRings as a replacement for the Freudenthal multiplicity
formula.
This was intended as a speedup, and it is quite effective in reducing the
time
for {{{sage -t --long weyl_characters.py}}} by a surprising
I can't pull from http://combinat.sagemath.org/patches/ .
Is it just me?
Dan
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/KBr0nUl6BXIJ.
To
I created a ticket #13461 with a patch that is another large speedup in
WeylCharacterRings.
The workhorse in WeylCharacterRings is (was) the Freudenthal multiplicity
formula that
computes the character of an irreducible representation. It occurred to me
that after
some one-time arithmetic (not
In addition to Macdonald polynomials there are the nonsymmetric Macdonald
polynomials
which for Type A are implemented in ns_macdonald.py by HHL
(Haglund-Haiman-Loehr)
combinatorial algorithm. But one wants nonsymmetric Macdonald polynomials
for
all Cartan types.
It was discussed at Sage Days
Non symmetric mac donald polynomials are also implemented in
sage-combinat
in a more general patch on multivariate polynomials.
Thanks ... I guess that is the patch
trac_6629_abstract_ring_of_multivariate_polynomials_with_several_bases_vp.patch
Dan
--
You received this message because
In a recent post in this thread, Savdeep Sethi pointed out that at least
for certain computations
LiE is much faster than Sage for decomposing tensor powers of
representations. In analyzing
why this is true, I tried replacing the current algorithm, which is the
product_on_basis method
of
There is already an optional LiE spkg for Sage [1]. I don't know anything
about it, for example whether it even builds. But that would perhaps be a
place to start.
[1] http://www.sagemath.org/packages/optional/lie-2.2.2.p4.spkg
--
John
Currently sage can do most everything that LiE can
I have rebased 9265 so that it applies on 5.1 but I haven't uploaded it as
I wanted to rename it and make sure that I don't clobber anything else in
the 5.1 or 5.2 queues. The main problem is that even though the queue
applies on 5.2 sage does not run due -- so far -- to incorrect
I have rebased Jason's patch and against 5.2-rc0.I am checking the doctests
etc. When I am done I will repost the patch to trac and the queue.
There was a message on sage-release that Sage 5.2 is now
available. It would be good to test it on that.
I also uploaded the new patch to trac, where I had to rename the patch as
trac would not give me permission to delete some one else's patch. The
patch probably won't apply cleanly to 5.2-rc0 for trivial reasons (white
space)
It should apply cleanly to 5.2. Assuming you fix that and repost
Christian Stump wrote:
unfortunately, 9265 does not apply anymore on 5.1...
I think a lot of patches are broke on 5.1 right now. Here is a partial list.
trac_5457-review-as.patch
trac_9265_tableaux_categories_jb.patch
trac_12774-coxeter-ms.patch
The wiki says that the patch should apply cleanly to the *latest
development release*. What is confusing me is that the patches in the
queue, and those on trac, are typically applied on top of other patches so
I would have guessed that quite often they will not apply cleanly to the
Mark Shimozono wrote:
| P.P.P.S Daniel Bump, let me know when I can have a go at the extended
affine Weyl groups,
| Hecke algebras and their polynomial modules, etc.
I'm keeping my revisions to the extended affine patch in a separate patch
to be folded. I
have some debugging and further
Frederic,
I pushed a patch (coxeter_ms.patch) to the sage-combinat server.
Now you should get
sage: W=WeylGroup(['A',2])
sage: w=W.from_reduced_word([1,2,1])
sage: w.inversions()
[alpha[1], alpha[1] + alpha[2], alpha[2]]
which is much nicer.
--Mark
Jean Michel wrote:
The
I tried to do some computations with the existing Iwahori-Hecke
algebra module inside sage earlier this year. I needed to work over
the rational function field C(x), for an indeterminate x. In the end I
gave up and went back to using some gap3 code that I have, which
builds on chevie,
While checking tracker tickets, it seems that nobody is working on the
littelmann path model for crystals right now... Still someone wrote
this as todo in
http://www.sagemath.org/doc/reference/sage/combinat/crystals/highest_weight_crystals.html
Can you provide me with more information as
- tends to cause problems the first time, especially on mac machines
- takes forever, even if everything works
- if the queue is broken that morning, they are skrewed
The last problem has a solution, since you could clone the queue in advance,
test it, and don't update it. Clone from that
Hi Nicolas,
I saw your reviewer patch for #7922 (thanks).
There were a couple of further minor revisions
which are in the patch
trac_7922_alpha3-changes.patch
that I put in the combinat queue. The patch:
trac_7922-rebased-4.7.alpha3.patch
that is now on the trac server is the sum of
the
sage: T.dynkin_diagram_automorphism_w0()
When the Dynkin diagram has a nontrivial automorphism (of order
two except D4), the map alpha - -w0(alpha) may or not
coincide with this automorphism.
The issue is with type D_n.
If n is odd, then alpha - -w0(alpha) is a nontrivial permutation of
Anne wrote:
The standard name in the literature for the automorphism (which may be
trivial)
induced by -w0 is
the opposition automorphism
This seems better to me.
I was going to suggest making it a method of ClassicalCrystals (so it
would be
available for other crystals besides crystals of
Yes, it also exists for any Cartan type, but my impression was that then
it is called Lusztig involution. My plan is indeed to eventually implement
the Lusztig involution in CrystalOfTableauxElements. What do you think?
That sounds like the right approach. Actually the Lusztig involution
would
A lot of methods for tableaux are in the Tableau class which only make
sense for semistandard tableaux, such as `bump` or `schensted_insertion`.
Someone claimed there is a bug in schensted_insert. See:
http://trac.sagemath.org/sage_trac/ticket/8322
I do not know if they are correct.
Dan
The patch contains this:
ind = lambda i: (-w0.action(alpha[i])).support()[0]
This would be called for each element of hw, which
depends on the distance to the highest weight vector.
That's not so bad, but if you looped over the crystal and
computed the involution for every element, it would be
I just added a new patch on trac which implements the Schuetzenberger
involution on both words and tableaux and also the promotion operator
on tableaux of arbitrary shape:
http://trac.sagemath.org/sage_trac/ticket/10446
I have the impression this is for Type A only. But the Schutzenberger
I wrote:
Unfortunately, trac_7922 may have a problem. I have been unable make good
pickles for:
_class__sage_combinat_root_system_weyl_characters_WeylCharacterRing_class_w
ith_category__.sobj
_class__sage_combinat_root_system_weyl_characters_WeylCharacter__.sobj
Luckily there is no
I just pushed a patch to the combinat queue that addresses a
few issues. It is called trac_7922-revisions3.patch.
Ah, another point: running pyflakes on weyl_characters.py points out
the following:
weyl_characters.py:2104: undefined name 'is_even'
weyl_characters.py:2107:
Unfortunately, trac_7922 may have a problem. I have been unable make good
pickles for:
_class__sage_combinat_root_system_weyl_characters_WeylCharacterRing_class_with_category__.sobj
_class__sage_combinat_root_system_weyl_characters_WeylCharacter__.sobj
I tried reverting to a version before the
Nicolas wrote:
Note: for whatever it's worth, one can disable product_on_basis, and
have the code still run. I did not check if that made any speed
difference.
Taking out product_on_basis turns out to be a speedup, so I will have
to post another version of the patch.
Dan
--
You received
I won't fold it on the combinat queue, but if I agree with
everything I'll repost it on the trac server.
Whatever is practical to you.
I added one small patch to the combinat queue, and in my own queue
I folded the patches and posted to trac. I didn't qfold them on the
combinat
server
On the subject of pickling I just found out the hard way that the pickle jar
is no longer tested by default, since trac_10712, which was merged in 4.6.2
marks the following test in sage_object.pyx long time that tests the
pickle jar.
- sage: print x; sage.structure.sage_object.unpickle_all()
+
Here is the status of #7922.
As I noted earlier, the timing issue is apparently fixed by
making _weight_multiplicities a cached method, and the
caching can be removed from product_on_basis.
Nicolas has a patch called trac_7922-review-nt.patch.
Some of his comments can be implemented, others not
- For #7922: understanding why in your example the hash function gets
called sooo often. For this, we should look at a smallest possible
example where hash is obviously called too often.
- Independently on #7922: creating a new ticket for optimizing hash
and equality tests for
- For #7922: understanding why in your example the hash function gets
called sooo often. For this, we should look at a smallest possible
example where hash is obviously called too often.
I have discovered that making _weight_multiplicities a cached method
seems to fix the timing
On this example, it's 20% faster; I guess the gain would increase on
larger elements. Besides it does not depend on the basis index to be
sortable.
I applied the two patches trac_7922-reviewer-nt.patch and trac_7922-
hash-nt.patch.
Something is wrong, however. Before the patches, the
On Feb 15, 7:53 am, Ben Salisbury bsalisbu...@gmail.com wrote:
Thanks very much!! My hope is to implement types B, C, D, and G. If
I'm successful, I will be sure to write back. Thanks again for the
help
Ben
The working Type A code that I showed you certainly needs
polishing and there
://sporadic.stanford.edu/bump/xtal/binfinity.sage
It might give you some ideas.
The crystal code is in sage/combinat/crystals/ . It was mostly
written by Anne Schilling but others (including myself) contributed
and are familiar with it, in case you have more specific questions.
Dan
--
You received
Benjamine Jones wrote:
I've looked over the plot code in WeightLatticeRealization. I think
perhaps the two sets of plotting code could co-exist, one in
RootLatticeRealization (or wherever) and mine in WeylCharacterRing.
The two sets of code have some things in common, but the plots are
- In the root and weight lattice, the default coordinate system
should be given by the natural basis. I.e. in the root lattice in
rank 2, alpha_1 should have coordinates (0,1) and alpha_2 (1,0).
What basis is this? (What would the basis be for C3?)
One natural basis would be the
Dear Dan and Nicolas!
As I said, I posted a revised patch on trac which includes Nicolas' review
patch.
I reinstalled the old crystal pickles and ran
lolita-3:pickle_jar anne$ sage -t -force_lib
devel/sage/sage/structure/sage_object.pyx
sage -t -force_lib
I need to know this too, for #7922. Maybe Nicolas or Mike Hansen could
comment.
On Feb 8, 11:06 pm, Anne Schilling a...@math.ucdavis.edu wrote:
What is the procedure? Looking back at
#8911http://trac.sagemath.org/sage_trac/ticket/8911
the new pickle jar was just attached to the ticket.
Let's make a deal then: I'll try to write soon a draft of patch
improving the documentation of unpickle_all to give detailed
explanations on the procedure. And I let you finalize this patch
according to your experience while you try out the procedure.
OK!
My main concern here is that #10632
I wrote:
Meanwhile, here is a relevant message from Mike Hansen:
http://groups.google.com/group/sage-combinat-devel/msg/8b826e732d699cf0
I also found this useful web page:
http://ask.sagemath.org/question/123/what-is-the-standard-pickle-jar-for-and-how-do-i
So assuming your shell is bash,
I wrote:
For me this fixed three out of four tests in sage/structure/sage_object.pyx. I
still get a failure with:
_class__sage_combinat_crystals_tensor_product_CrystalOfTableauxGeneric_with_category_element_class__.sobj
This was wrong. (I clearly must have copied the wrong pickle.)
I
I wrote:
This was wrong. (I clearly must have copied the wrong pickle.)
I repeated everything as in my previous email. The pickling failure is in:
_class__sage_combinat_crystals_tensor_product_CrystalOfTableaux_with_category_element_class__.sobj
The pickles that are in
After Nicolas' revised #10723 and Anne's two patches there is
one error after sage -t on doc/en/thematic_tutorials/lie/affine_crystals.rst.
File
/home/bump/src/sage-4.6.2.alpha3/devel/sage-queue/doc/en/thematic_tutorials/lie/affine_crystals.rst,
line 165:
sage: K.classical_decomposition
There are some other failures after Anne's patch in
sage_object.pyx.
I had a related query in this message from last September,
in connection with #7922. I think the answer is that the
release manager should rebuild the pickle jar, but I am
not certain of this.
Perhaps Nicolas can comment?
Nicolas wrote:
Yup, I guess we can safely update the pickle jar in that case
also. But that's not the release manager's job :-)
I was hoping it was.
See the
documentation of sage.structure.sage_object.unpickle_all for how to
I am looking at #10485. I see Anne posted a new version
overnight.
Comment 1.
I built it with the -j option to use the jsfonts.
sage -docbuild thematic_tutorials -j html
With the jsmath option the {1,2, ..., } in this line:
B^{r,s} \cong B(s\omega_r) \quad \text{as a
Nicolas, could you have a look why #10723 does not apply to sage-4.6.2?
For me with sage-4.6.1 everything applies and works.
The patch itself is not at the trac page. What is
at the trac page is a *link* to the patch and the
description:
patch under construction on the Sage-combinat queue
I
Nicolas, could you have a look why #10723 does not apply to sage-4.6.2?
For me with sage-4.6.1 everything applies and works.
I'm guessing that #9074 was merged and slightly clashes with
#10723. It seems to have changes to the part of graph_latex.py
where there is a conflict.
However that does
Anne wrote:
The new patch now depends on #10723 which is available on the sage-combinat
server.
The patch for #10723 does not apply cleanly to sage-4.6.2.alpha3.
I took the patch from the combinat queue, but since it would be
good to get #10632 merged in sage, I'm asking whether #10723
can
I'm looking at #10632.
Comment 1.
After the patch, I observe the following. Line 757 of tensor_product.py
contains:
shapes = tuple( tuple(shape) for shape in shapes )
I think here the making of a tuple is important because a tuple is immutable,
a list is not.
To illustrate, suppose take
Ops, but all those comments are assuming that #7922 is applied,
which I still haven't reviewed ... Ok, that going up my TODO pile ...
The code snippet I posted does not assume #7922.
At this moment #7922 needs work since it changes the
syntax of a few things enough to break some tests in
Nicolas wrote:
This looks very related to what Vivianne (and Adrien and Nicolas) is
implementing around Schubert polynomials and the like. Vivianne: can
you already compute demazure characters with your code?
(WeylCharacterRing is basically the group algebra of the ambient
lattice)? If yes,
correct:
http://match.stanford.edu/bump/patches/demazure.patch
After this patch you can do this:
sage: B2 = WeylCharacterRing(B2)
sage: b2 = WeightRing(B2)
sage: W = B2.space().weyl_group(prefix=s)
sage: [s1,s2] = W. simple_reflections()
sage: w0 = W.long_element()
sage: [b2(h).demazure(w0) for h
I too needed some code to compute with Demazure characters using the
weight ring.
I agree that this is useful independent of the Demazure characters as
implemented
in the crystal code.
What we did was just to make a standalone program that did what we
needed, but it would make a good enhancement
For Type B2 only, we can do this:
sage: C=FastCrystal(B2,shape=[3/2,1/2])
Of course it is desirable to be able to do this for higher rank, and
the
latexing is a separate issue.
Dan
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post
I sent Anne a private reply to this, but in essence, there should be a
chapter on
affine crystals right after the chapter on classical crystals.
Dan
On Dec 16, 12:09 am, Anne Schilling a...@math.ucdavis.edu wrote:
Dear Dan,
How should I go about adding to your thematic tutorial for affine
Usually when I replace a patch, I click the little box that says
replace earlier version? (There may be pros and cons for this.)
The other thing I do (since once someone complained) is to make
it very clear in the description what needs to be applied, so when
I reviewed the patch yesterday I
There's still one doctest failure, because you forgot to remove the
line:
sage: from sage.combinat.dict_addition import remove_zeros
in dictionary_addition.pyx. Could you fix that?
Actually there was another doctest failure which is surely not due to
your patch in r.py.
File /home/bump/src
Thank you!
Done! Positive review.
Anne
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
Unless someone has a better idea, or objects, maybe the patch should
just update the test result
in hopf_algebras_with_basis so that the test passes.
The new method with the less nice name bound method ... is much
faster. I asked
It is called at the end of dict_linear_combination and as well at the
end of dict_addition. That's why I chose to make it an extra method.
Do you recommend to put it back into those places to save the function
call overhead (isn't this nanosecs)?
The dictionary might be quite large. So it
On Oct 18, 5:06 am, Christian Stump christian.st...@gmail.com wrote:
I just saw that Florent prepares the patches going into 4.6. I wanted
to ask if someone has a little time to review this patch #9651.
Thanks and have a nice week, Christian
I can try to review it.
BTW it would be good if
- John, would you feel like reviewing Christian's patch?
Is this #9651?
Dan
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send
I wonder if we can figure out why I was getting slower times for
the experiment I did.
- Multiplication cannot be handled using CFM. But inside the methods
providing those, one can still get a speed up for addition by using
F.sum( iter ) or F.linear_combination( iter ) rather than sum( iter )
On Sep 19, 5:05 pm, Christian Stump christian.st...@gmail.com wrote:
Salut!
It is not yet in the queue. If that makes your life simpler, you are
welcome to add it there.
This patch does not apply cleanly. I have tried out-of-the-box
sage-4.5.3.rc0, sage-4.5.2 and sage-4.5.2 with the
Nicolas wrote:
http://trac.sagemath.org/sage_trac/ticket/9651
It is not yet in the queue. If that makes your life simpler, you are
welcome to add it there.
This patch does not apply cleanly. I have tried out-of-the-box
sage-4.5.3.rc0, sage-4.5.2 and sage-4.5.2 with the combinat queue
patch for this:
http://sporadic.stanford.edu/bump/trac_7922.patch
If running the old code all WeylCharacterRings are created with
cache=true then
the old code is faster.
If the old code is run omitting cache=true (which is not the default)
then the
new code is faster.
On one batch of tests
On Sep 2, 3:33 am, Bruce brucewestb...@gmail.com wrote:
I am trying to construct the fee module on the set of instances of a
class G.
It would be good to give a complete example, that is, with a
particular G.
Can anyone tell me what I am doing wrong and/or explain this?
Thanks
--
You
On Sep 1, 1:37 am, Bruce brucewestb...@gmail.com wrote:
Can you compile sage from scratch?
Yes. I have a Linux machine and John Cremona installed sage 4.5.2
2010-08-05 for me from scratch.
Great.
To install the patch, download it by going to
http://trac.sagemath.org/sage_trac/ticket/9838
have any chance for handling this?
I have a working partial implementation. Could you look at this and
tell me if this is what you have in mind:
http://sporadic.stanford.edu/bump/alt_weyl_character_rings.patch
This implements quite a bit of the functionality of
WeylCharacterRings.
What is missing
Bruce wrote:
Thanks Dan. I would be happy to try if I knew what to do!
In order to try the patch (short of waiting for the patch to get
merged into sage)
you need a patched version of sage.
Can you compile sage from scratch?
That is, download sage-4.5.2.tar from here:
Bruce wrote:
I have tried to construct the WeylCharacterRing with base_ring
polynomials in q with integer coefficients. There were no complaints
but it seemed to take q to be one of the monomials.
This is a bug. I note that this doesn't happen if we omit the
coroot style.
Nicolas wrote:
I have uploaded a patch for this problem here:
http://trac.sagemath.org/sage_trac/ticket/9838
Bruce, could you try the patch and see if it solves
your problem?
Dan
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group,
* I agree with Dan that the role of the weight/coweight lattice is currently
a little
unclear in the patch. Proposition 6.5 of Kac which is cited states that
the extended
affine Weyl group is the semidirect product of the finite Weyl group and
translations
in the coweight
I see Anne created a ticket #8811 which I think is supposed to be
for this patch.
I have played with the patch some and it works well for type A2.
Dan
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send email to
There is a homomorphism of the coroot lattice into the affine
Weyl group.
At least in principle, this can be computed by taking a fundamental
alcove F and translating it by an element d of the coroot lattice,
then
seeing what alcoves lie between F and F+d. It seems to me that
it would be
It looks like the algorithm I asked for in my previous message is in
the patch reduced_word_of_translations_nt.patch which is in the
combinat queue.
What are the prospects for getting this into Sage? Making a
trac ticket for it?
Dan
--
You received this message because you are subscribed to
The patch applies without any problems to Sage 4.4.
I have one concern which is that the relevant lattice
is the coroot lattice and (for the extended affine Weyl
group) the coweight lattice.
In the example, we have this:
We start by translations by elements of the coroot lattice::
Shouldn't we be working with the fundamental coweights, not the
fundamental weights?
In this example it makes no difference since the root system is
simply-laced.
Dan
I didn't quote enough of the context in weight_lattice_realization
to show what I mean.
sage: R =
In case it would help review this patch, let me try to explain it.
The problem is to give a sort of classification of most maximal
subgroups of Lie groups so that we can give branching rules.
The subgroups in question are of the type O(n) x O(m) in O(n+m)
or Sp(n x m) in Sp(n) x Sp(m).
In principle Dan Bump volunteered to review this patch, but I have not
heard anything. If anyone else is willing to review it to get it merged
into sage-4.4 that would be great. It fixes some bugs in the crystal code.
Sorry. I've been quite busy with teaching. I'll try to do this
weekend.
BTW
These tickets have patches awaiting review. After applying the
relevant patches at those tickets and rebuilding the whole Sage
standard documentation, you would get something like what is available
at
http://sage.math.washington.edu/home/mvngu/8470-newdoc/
The tutorials all look pretty good.
1 - 100 of 124 matches
Mail list logo
