On Thu, Jan 07, 2010 at 12:02:05PM -0800, Anne Schilling wrote:
> I posted a positive review on the trac server.
Thanks much!
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil"
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Go
bump wrote:
> The code reduces everything to the multiplication of a basis element
> T_w by a generator T_i (product_by_generator_on_basis). If you have a
> way to detect when the relation applies (here if ws_i as both i and
> i+1 as descents?), then you can adapt this method to return 0. You
> > The code reduces everything to the multiplication of a basis element
> > T_w by a generator T_i (product_by_generator_on_basis). If you have a
> > way to detect when the relation applies (here if ws_i as both i and
> > i+1 as descents?), then you can adapt this method to return 0. You
> >
Hi Anne,
On Wed, Jan 13, 2010 at 11:49:38PM -0800, Anne Schilling wrote:
> I recently asked Nicolas whether it is easy to amend the Iwahori Hecke
> algebra code to mod out by further relations? For example to impose
> T_i T_{i+1} T_i = 0 or something like this. He suggested to discuss this
I recently asked Nicolas whether it is easy to amend the Iwahori Hecke
algebra code to mod out by further relations? For example to impose
T_i T_{i+1} T_i = 0 or something like this. He suggested to discuss this
on the mailing list since others might be interested:
> The code reduces everything t
I posted a positive review on the trac server.
Anne
bump wrote:
I made these changes and also added Nicolas as an author. The
reposted patch is on the trac server.
Dan
If you (Dan and Nicolas) would like to submit the patch jointly,
I am happy to review. Here are a couple of small comments:
I made these changes and also added Nicolas as an author. The
reposted patch is on the trac server.
Dan
> If you (Dan and Nicolas) would like to submit the patch jointly,
> I am happy to review. Here are a couple of small comments:
>
> - Perhaps it would be better to name the file
> sage.algeb
Daniel Bump wrote:
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
On Wed, Jan 06, 2010 at 12:06:12PM -0800, Anne Schilling wrote:
> >Now why did I deem CoxeterGroups "general purpose" but not the
> >categories used, e.g., for NonCommutativeSymmetricFunctions? Mostly
> >because there are Coxeter groups in different spots in Sage: for
> >example the symmetric grou
sage.algebras.iwahori (as it currently is)
sage.combinat.iwahori (similar to sage.combinat.sf / ...)
sage.combinat.root_system.iwahori (similar to sage.combinat.weyl_group)
I debated where to put it. All three places seem logical.
Anyone else feedback?
I would say either
sage.algebras.iwahor
> 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
On Wed, Jan 06, 2010 at 08:36:38AM -0800, Daniel Bump wrote:
> > 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
> 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
Dear Dan,
On Wed, Jan 06, 2010 at 07:11:09AM -0800, bump wrote:
> > Ok, glad to see that we agree. Actually, we want to accept a Coxeter
> > group I think. I'll do that today.
>
> OK.
Done an reposted.
For the record: the category/free_module refactorization allowed to
get rid of about
> Ok, glad to see that we agree. Actually, we want to accept a Coxeter
> group I think. I'll do that today.
OK.
> What about the second question:
>
> - Should we use q in QQ['q'] as default parameter for q_1?
I don't know whether it would be worth it. It doesn't seem too much
work for the u
On Tue, Jan 05, 2010 at 09:04:13PM -0800, bump wrote:
> I reposted the iwahori.patch on the trac server. The posted version
> includes
> Nicolas' two patches from the combinat queue.
Ok.
> I did not qfold the patches on the queue, but if you want to do
> that, the resulting patch
Ok.
> There is
I reposted the iwahori.patch on the trac server. The posted version
includes
Nicolas' two patches from the combinat queue.
I did not qfold the patches on the queue, but if you want to do that,
the resulting
patch
There is one issue which remains. There is a query in the source
(from Nicolas) as t
On Sun, Jan 03, 2010 at 08:55:29PM -0800, bump wrote:
> > In practice, this would mean that the implementation of the KL
> > polynomials would be made entirely in term of q_1 and q_2, leaving the
> > responsibility of choosing an appropriate field containing a square
> > root of q to the user (or s
> In practice, this would mean that the implementation of the KL
> polynomials would be made entirely in term of q_1 and q_2, leaving the
> responsibility of choosing an appropriate field containing a square
> root of q to the user (or some wrapper).
The current implementation of the Iwahori Hecke
By mistake I posted in the wrong thread. I was able to remove it
from the archive and repost it correctly, but if you subscribe to the
list
you saw it twice. Sorry.
Dan
On Jan 2, 10:12 pm, Daniel Bump wrote:
> I have revised both the Kazhdan-Lusztig polynomial and Iwahori
> Hecke algebra patches
20 matches
Mail list logo
