I have a branch called:
remotes/origin/public/combinat/15361-branching-rules
I the repository, switched to this branch, calling the local branch
15361-branching-rules. I did some work, then tried to push. Per the
instructions at the tentative conventions page
(http://wiki.sagemath.org/TentativeC
> Right now, I am having some trouble applying the patch by Benjamin Jones:
> though it seems to apply, it doesn't. I must be doing something
> stupid...
The patch is a couple of years old, and we wouldn't expect it
to apply. It contains some code (for Demazure operators) that is
no longer relev
> 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: A4(1,0,0,
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.
http://patchbot.sagemath
> 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).
> B
" For consistency, what about adding a style 'coroots' for
" weight_multiplicities() too?
After the patch #13461 you can do the following:
sage: A2=WeylCharacterRing("A2",style="coroots")
sage: rep = A2(1,0)
sage: a2 = WeightRing(A2)
sage: a2(rep)
a2(0,-1) + a2(-1,1) + a2(1,0)
However the inte
> Pushed. Hmm, still getting a little conflict on
> concrete_combinatorial_statistics_and_maps-cs.patch after merging. I
> guarded it for now. Off to bed!
It's good to see the queue working, at least for 5.2, again.
Dan
--
You received this message because you are subscribed to the Google Gr
> 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 depr
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
root_system_plot_refacto
> 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 rep
> 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.
http://boxen.math.washington.edu/home/relea
> 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
> r
The symmetric function patch #5457 is a big step towards being
able to work with the Hopf algebra of symmetric functions.
Here's an interesting fact. Recall that the elements of the
symmetric function Hopf algebra can be interpreted as
representations of the symmetric group. For example, the
Schu
> 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 wro
> 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, be
> 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 informat
> - 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 r
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 thre
> It seems that your patch has a problem to be applied to the current sage
> 4.6.2.
The patch was tested with 4.7.alphas (because we hope for it to be merged
soon). The syntax of classical_crystals.py at the top of the file
has changed since 4.6.2. So it doesn't merge.
One possibility would be t
> 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
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
c
> 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
-
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
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: u
> I just pushed my changes on the Sage-Combinat queue. The code uses
> standard coercion now.
Thanks! At the moment, I can say that after your patch,
the code seems to be about the same speed as before,
which is good.
> I won't touch the thing tomorrow, so feel free to fold all the 7922
> patche
> Can you elaborate? Is there a compelling technical reason?
Well, what you are suggesting is a little tricky. Two
rings will be created at the same time, and the
multiplication will be implemented by coercing from
the WeylCharacterRing to the WeightRing, multiplying,
and coercing back. And I see
The following pickles saved in the pickle jar warn of deprecation
when they are loaded:
_class__sage_combinat_words_word_AbstractWord__.sobj
_class__sage_combinat_words_word_Word_over_Alphabet__.sobj
_class__sage_combinat_words_word_Word_over_OrderedAlphabet__.sobj
_class__sage_combinat_words_wor
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.
I have discovered that making _weight_multiplicities a cached method
seems to fix the timing prob
> - 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
> - Is it reasonnable that hash is called 4 000 000 times in your
>example? Are there huge elements being manipulated?
No, I don't think that is reasonable. So there must be something
fishy going on.
The character of A7 (SL(8)) in question has 792 weights with nonzero
coefficient. This is n
> I can get in touch. But before, are there any other tickets changing
> the pickle jar?
>
> #10632
> #7922
> #10354
In its current form 10632 does not change the pickle jar.
Dan
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post
> Hi. I'm new to programming, but I would like to attempt to create a
> Sage code for Kashiwara's B(infinity) crystal using Hong and Lee's
> semistandard Young tableaux description. My plan is to base my work
> on the crystal code already developed (i.e., definition of e(i) and
> f(i), translati
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 fun
Nicolas wrote:
> > Where do people think the main code for plotting should go? In
> > WeightRingElement, WeylCharacterRing, or in weyl_character.py but
> > outside of any class (and have plot methods in both classes that call
> > this function?)
>
> In RootLatticeRealization.
I see the plotting
> 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 "devel/sage/sa
Here are some comments on #10744.
Very nice!
I do have some comments.
sage: A2=WeylCharacterRing("A2",style="coroots")
sage: a2=WeightRing(A2)
sage: rp=a2(A2(2,1))
sage: rp.plot()
Frequently one will want to call this for the character of
a representation. It would be good if one could:
A2(2,
I am returning to the question of timing issues with #7922.
I recall that for a variety of branching rules, I ran tests
with and without the test, and obtained the following
results:
Old Code48 seconds
New Code25 seconds
Old Code, cache=true18 seconds
This is
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 tmp/pickle
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 r
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 bas
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
> a
Anne wrote:
> Do you have the latest version of #10632 since I changed this on Friday
> and made the KR crystal use the new CrystalOfTableaux code instead of a
> tensor product.
Oops, I had overlooked that there is a new version of #10632. With the current
versions of #10732, 10632 and 10485, th
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?
htt
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()
> I am not sure I understand this comment. For me this section starts as:
> "The KR crystals `B^{n,s}` for types `C_n^{(1)}` and `D^{(2)}_{n+1}` were
> excluded from the above discussion."
> Could you be more specific?
OK, something interesting happens involving jsmath and the
cascading style sh
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 \{1,2,\ldots,n\}-cry
> 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 doe
> 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"
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 th
> I don't know if it's helpful to post so much code, but here is my code
> for the Demazure character and rank 2 plotting. The Demazure character
> code contains the same idea as bump's code.
There were a couple of mistakes in the code snippet that I posted.
Here is another attempt, probably cor
Anne wrote:
> If it is more convenient for you, I can include it into 10485.
This might be more strategic for speed of getting it merged. I emailed
you a revised .png file in a private message.
Dan
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-de
> 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
> Done and reposted.
I thought the docstring needed a bit of revision to reflect the
changes, so I added a patch to the queue called trac_7729_doc.patch.
I posted trac_7729_iwahori-hecke-algebra.2.patch to the server.
If you qfold trac_7729_doc.patch you will get identical to this
patch. I did n
> For the record: the category/free_module refactorization allowed to
> get rid of about 200 lines out of 700. Those were mostly lines of
> code; I kept all the doctests. Now that you have seen how this works,
> how would you feel doing something similar for WeylCharacters?
I agree that it should
> Dan: given the amount of change, let me know if it's best to keep the
> reviewer's patch separated, or to fold the two of them before you
> review my changes.
The reviewer patch is big enough that I need to study the changes,
so let's keep them separated for now.
About the tests, I several tim
I have revised both the Kazhdan-Lusztig polynomial and Iwahori
Hecke algebra patches and reposted them on the trac server.
http://trac.sagemath.org/sage_trac/ticket/7729
http://trac.sagemath.org/sage_trac/ticket/7751
Things that should be in coxeter.py have been moved there,
cached methods are
There is an enlargement of the affine Hecke algebra,
due to Iwahori and Matsumoto, which I don't know how
to implement in Sage. This is an issue for type A,
related to the difference between GL_n and SL_n.
Let us consider the case of ['A',2,1]. If p is a
prime element in a nonarchimedean local fie
I have revised both the Kazhdan-Lusztig polynomial and Iwahori
Hecke algebra patches and reposted them on the trac server.
http://trac.sagemath.org/sage_trac/ticket/7729
http://trac.sagemath.org/sage_trac/ticket/7751
Things that should be in coxeter.py have been moved there,
cached methods are
> Thanks! If you don't mind the overhead, I'd suggest to put your code
> on the Sage-Combinat patch server to ease playing around with it and
> merging/coordinating with related patches on the topic.
I was unable to get a working combinat queue. With sage-4.3.alpha1
I get errors in trac_7420-fix-
> Nice. We will want other representations as well (permutation
> representation, compact reduced word, ...). So this calls for some
> option like:
>
> sage: W = WeylGroup("B3", element_print_style = "reduced_word")
>
> Customizing the way the elements of a given parent are printed is a
> feat
I have what seems to be a working patch to compute
Kazhdan Lusztig polynomials at:
http://sporadic.stanford.edu/bump/patches/kazhdan_lusztig.patch
This implements the Bruhat order, Bruhat interval and
Kazhdan-Lusztig polynomials for Weyl groups.
The patch adds three optional parameters to WeylG
> I also have my wrapping of Coxeter3 that I recently started to clean
> up to make a proper spkg. That exposes Hecke algebras, Bruhat
> interval-related code, and the KL polynomials. It's my goal to have
> something soon.
Wrapped Coxeter3 will probably be superior to what I would write for KL
> Would it be natural to use IwahoriHeckeAlgebra(W, q1, q2)?
Maybe this is the best idea.
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 fro
Yes, http://wiki.sagemath.org/HeckeAlgebras
is exactly what we need. These are so fundamental that they should
be in Sage.
> I think rewriting from scratch an implementation of the generic Hecke
> algebra in the T_w basis, with two parameters q1 and q2 would be a
> good starting point. With the c
I am doing some calculations in Iwahori Hecke algebras.
By this I mean the deformation of the group algebra of
a Weyl group in which the generators corresponding to
the simple reflections satisfy t_alpha^2=(q-1)*t_alpha+q,
where q is a deformation parameter.
For type A a version is implemented in
racters, symmetric functions, enumerated sets, semigroups, Hopf
> algebras, by Daniel Bump, Florent Hivert, Anne Schilling, and many others.
Dan
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group,
> I just ran each long test individually, and annotated them with how
> much time they took (on my macbook pro). They are indeed all below
> 30s, except for a big E8 test which takes 160s. I marked that one as
Oops, E8(1,0,0,0,0,0,0,0) has degree 3875. That could be slow.
I think I probably meant
> 3) The time for weyl_characters.py to complete on -long has gone up
> to 250s or so. I'm not sure if this is due to adding more expensive
> tests or a speed regression. This currently runs twice as long as
> any other single file on -long.
The patch #5794 adds a lot of branching rules, and te
> By the way: what's the status of this spkg? Is there some
> documentation somewhere of what can be done with it from Sage? (I just
> tried lie-2.2.2.p3 but it does not seem compile on my 32bits i686
> ubuntu box).
William Stein has stated that LiE would not be made a
standard package because i
Nicolas wrote:
> > Is it possible to conjecture a timetable for the root system
> > patch (#4326)?
>
> Given how wrong my previous conjecture has been, I am reluctant saying
> anything, though I am finally quite hopeful. If the category patches
> indeed get reviewed quickly, we can give it a s
> Is this question addressed to me, or ?
Yes.
Note that the root system patch depends on the category
patches, which why it came in this thread. Various other
long pending patches depend on it.
Dan
--~--~-~--~~~---~--~~
You received this message because you a
> The next Sage version will be 4.2. Send me a list of technical
> patches with positive review related to categories, and they can be
> the *first* to go in. I also see 4.2 as being a relatively quick
> release (compared to the extremely long 4.1.2).
Is it possible to conjecture a timetable f
I'll do this (and quickly). I've confirmed that the patch
seems to work out of the box with Sage 4.1.1.
Dan
> Hi,
>
> Could someone please review the new sage-combinat ticket #6839 (new
> enhancement)
>
> - Implemented crystal of letters for type E7
>
> - Added the method that goes to the h
77 matches
Mail list logo
