Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

On Saturday, 22 November 2014 12:23:31 UTC+11, Travis Scrimshaw wrote:
>
>  Something which would be benefit from having a category for Hecke algebra 
> representations would be methods for constructing the Grothendieck group, a 
> list of simples (up to isomorphism), and a canonical place to look for 
> constructing examples (via ``an_element()``).
>

Yes, this would be a nice feature.
 

> For general representation categories, we'd have an abstract method 
> ``representation_action()``
>

Currently, I have this built into the class 
IwahoriHeckeAlgebraRepresentation.
 
This week will be a nightmare for me, so I'll try and finalise this patch 
next week. I now have the general framework in place and it remains to 
document and doc-test the code (always fun), to add the explicit formulas 
for the different actions (corresponding to the different bases). All of 
this is straightforward but will of course take longer than I expect:)

I have realised that I do have one issue that I am unsure what to do with: 
I am implementing seminormal representations for the the algebras of type 
G(r,1,n). As special cases these include the Iwahori-Hecke algebras 
algebras, with equal parameters, of types A and B. The action of the Hecke 
algebras of type A on my modules will be easy because the Hecke algebra 
generator T(r) corresponds to the simple reflection (r,r+1). 

Unfortunately, the action of the Hecke algebras of type B is going to be 
painful because the the subalgebra  is isomorphic to a 
Hecke algebra of type A with the additional generator T(n) satisfying the 
relation T_{n-1}T_nT_{n-1}T_n=T_nT_{n-1}T_nT_{m-1}. The generator T(n) is 
conjugate to the generator that I would like to use: I would prefer the 
algebra to be generated by T_0, T_1,...,T_{n-1} where
T_0T_1T_0T_1=T_1T_0T_1T_1 etc., These two presentations differ by a diagram 
automorphism, but it is not entirely clear to me how T(n) acts on my 
representations...perhaps this is easy, but I need to think about this.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Hey Andrew and Nicolas,
   I've probably mentioned this before, but I think we should figure out 
how we want to handle categories for representations in general. I would 
like this for Lie algebras (equiv. universal enveloping algebras), quantum 
groups, and general groups (equiv. group algebras). Something which would 
be benefit from having a category for Hecke algebra representations would 
be methods for constructing the Grothendieck group, a list of simples (up 
to isomorphism), and a canonical place to look for constructing examples 
(via ``an_element()``).

   So my thoughts (if you've heard this before, feel free to skip) on this 
would be to construct a category parameterized by a Hecke algebra ``H`` 
which is a subcategory of the category of modules over ``H.base_ring()``. 
For general representation categories, we'd have an abstract method 
``representation_action()`` (the name can change, I didn't think too hard 
about this) that the user must implement and which we use throughout the 
category and with some default implementation of ``get_action()`` which 
calls ``representation_action()`` when passed an element of ``H``. In this 
case specifically, we could define a generic ``representation_action()`` 
which converts an element to the T_i basis and calls ``T_action(i)`` 
(again, probably a better name out there).

   Although for now we can just have a base class for all Hecke algebra 
representations, and there is not a clear and obvious gain to me at present 
from defining such a category.

Best,
Travis


On Friday, November 21, 2014 4:16:13 PM UTC-8, Andrew wrote:
>
>
>
> On Saturday, 22 November 2014 10:24:43 UTC+11, Nicolas M. Thiery wrote:
>>
>> Hi Andrew, 
>> Hmm, I haven't taken the time to think with a pen and paper, but I 
>> don't guarantee that the what the super call do is as straightforward 
>> as it ought to, given that the instance of A being initialized will 
>> end up being in a subclass A_with_category, and similarly for the 
>> others.  Does it work if instead you call explicitly A.__init__ in 
>> B.__init__, and so on? 
>>
>
> Hi Nicolas,
>
> I fixed my problem so the code is working now. It is possible that there 
> are some issues with the super calls but as far as I can tell it is working 
> as I expect.
>
> One question that I should ask you, however, is the following. I have a 
> suspicion that I should define a category for the Hecke algebra 
> representations, however, I don't know what the benefits are of doing this 
> or how to do it. Certainly the code seems to work without this (not that I 
> have added extensive tests yet or properly implemented the mathematics), 
> but if this is necessary, or desirable, I would like to understand what 
> this gives me over and above having a dedicated class for Hecke algebra 
> representations.
>
> Andrew
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

On Saturday, 22 November 2014 10:24:43 UTC+11, Nicolas M. Thiery wrote:
>
> Hi Andrew, 
> Hmm, I haven't taken the time to think with a pen and paper, but I 
> don't guarantee that the what the super call do is as straightforward 
> as it ought to, given that the instance of A being initialized will 
> end up being in a subclass A_with_category, and similarly for the 
> others.  Does it work if instead you call explicitly A.__init__ in 
> B.__init__, and so on? 
>

Hi Nicolas,

I fixed my problem so the code is working now. It is possible that there 
are some issues with the super calls but as far as I can tell it is working 
as I expect.

One question that I should ask you, however, is the following. I have a 
suspicion that I should define a category for the Hecke algebra 
representations, however, I don't know what the benefits are of doing this 
or how to do it. Certainly the code seems to work without this (not that I 
have added extensive tests yet or properly implemented the mathematics), 
but if this is necessary, or desirable, I would like to understand what 
this gives me over and above having a dedicated class for Hecke algebra 
representations.

Andrew

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

Hi Andrew,

On Fri, Nov 21, 2014 at 05:55:51AM -0800, Andrew wrote:
>I'm currently going around in circles with some CombinatorialFreeModule
>woes. The previous code for these "alternating seminormal forms works,
>but in order to cope with the many variations of seminormal
>representations that I decided to implement working I've have had to
>jazz things up quite a lot. Now my basic class structure looks
>something like this:
>from sage.combinat.free_module import CombinatorialFreeModule
>from sage.rings.polynomial.polynomial_ring_constructor import
>PolynomialRing
>class A(CombinatorialFreeModule):
>def __init__(self, base_ring, basis_keys, prefix='a', **kwargs):
>super(A,self).__init__(base_ring, basis_keys, prefix=prefix,
>**kwargs)
>class Element(CombinatorialFreeModule.Element):
>pass
>class B(A):
>def __init__(self, base_ring, basis_keys, prefix='b', **kwargs):
>super(B,self).__init__(base_ring, basis_keys, prefix=prefix,
>**kwargs)
>class C(B):
>def __init__(self, shape, prefix='c', **kwargs):
>base_ring=PolynomialRing(Integers(), 'q')
>super(B,self).__init__(base_ring, shape.standard_tableaux(),
>prefix=prefix, **kwargs)
>This simplified code works fine. For example,
>sage: C(Partition([3,2])).an_element()
>2*c[[[1, 2, 5], [3, 4]]] + 3*c[[[1, 3, 4], [2, 5]]] + 2*c[[[1, 3, 5],
>[2, 4]]]
>Unfortunately my real code does not work, having issues like:
>sage: rep=SeminormalRepresentation([2,1]); rep
>SeminormalRepresentation([2,1])# seems to work
>OK
>sage: rep.an_element() # try to construct an element
>sentations.SeminormalRepresentation_with_category.element_class at
>0x119a88c80>) failed: AttributeError:
>'SeminormalRepresentation_with_category' object has no attribute
>'_prefix'>
>sage: rep(StandardTableau([[1,2],[3]]))
>AttributeErrorTraceback (most recent call
>last)
>...
>AttributeError: 'SeminormalRepresentation_with_category' object has no
>attribute '_basis_keys'
>Does anyone have an idea of what is going wrong. Part of the issue
>might be all of the super calls, but I tried taking though ut and
>explcitly calling the previous class (they are linearly ordered), but
>this doesn't help.

Hmm, I haven't taken the time to think with a pen and paper, but I
don't guarantee that the what the super call do is as straightforward
as it ought to, given that the instance of A being initialized will
end up being in a subclass A_with_category, and similarly for the
others.  Does it work if instead you call explicitly A.__init__ in
B.__init__, and so on?

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

Actually, I have found the problem, all of my own doing...

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Hmmm... I don't see anything from a quick read of the code why this is 
going wrong. I'll take a more detailed look today.

Best,
Travis


On Friday, November 21, 2014 5:55:51 AM UTC-8, Andrew wrote:
>
> I'm currently going around in circles with some CombinatorialFreeModule 
> woes. The previous code for these "alternating seminormal" forms works, but 
> in order to cope with the many variations of seminormal representations 
> that I decided to implement, I've have had to jazz things up quite a lot. 
> Now my basic class structure looks something like this:
>
> from sage.combinat.free_module import CombinatorialFreeModule
> from sage.rings.polynomial.polynomial_ring_constructor import 
> PolynomialRing
>
> class A(CombinatorialFreeModule):
> def __init__(self, base_ring, basis_keys, prefix='a', **kwargs):
> super(A,self).__init__(base_ring, basis_keys, prefix=prefix, **
> kwargs)
>
> class Element(CombinatorialFreeModule.Element):
> pass
>
> class B(A):
> def __init__(self, base_ring, basis_keys, prefix='b', **kwargs):
> super(B,self).__init__(base_ring, basis_keys, prefix=prefix, **
> kwargs)
>
> class C(B):
> def __init__(self, shape, prefix='c', **kwargs):
> base_ring=PolynomialRing(Integers(), 'q')
> super(B,self).__init__(base_ring, shape.standard_tableaux(), 
> prefix=prefix, **kwargs)
>
> This simplified code works fine. For example,
>
> sage: C(Partition([3,2])).an_element()
> 2*c[[[1, 2, 5], [3, 4]]] + 3*c[[[1, 3, 4], [2, 5]]] + 2*c[[[1, 3, 5], [2, 
> 4]]]
>
> Unfortunately my real code does not work, having issues like:
>
> sage: rep=SeminormalRepresentation([2,1]); rep
> SeminormalRepresentation([2,1])# seems to work OK
> sage: rep.an_element() # try to construct an element
>  iwahori_hecke_algebra_representations.
> SeminormalRepresentation_with_category.element_class at 0x119a88c80>) 
> failed: AttributeError: 'SeminormalRepresentation_with_category' object 
> has no attribute '_prefix'>
> sage: rep(StandardTableau([[1,2],[3]]))
> AttributeErrorTraceback (most recent call last
> )
> ...
> AttributeError: 'SeminormalRepresentation_with_category' object has no 
> attribute '_basis_keys'
>
> Does anyone have an idea of what is going wrong. Part of the issue might 
> be all of the super calls, as perhaps some of the the classes higher up are 
> not using super, but I tried taking out all ofthe super calls and, 
> instead,  explicitly calling the previous classes (they are linearly 
> ordered), and unfortunately this doesn't help.
>
> For anyone feeling masochistic, the full code is at trac:17303 
>  (it uses 6.5beta0)
>
> Andrew
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

I'm currently going around in circles with some CombinatorialFreeModule 
woes. The previous code for these "alternating seminormal forms works, but 
in order to cope with the many variations of seminormal representations 
that I decided to implement working I've have had to jazz things up quite a 
lot. Now my basic class structure looks something like this:

from sage.combinat.free_module import CombinatorialFreeModule
from sage.rings.polynomial.polynomial_ring_constructor import PolynomialRing

class A(CombinatorialFreeModule):
def __init__(self, base_ring, basis_keys, prefix='a', **kwargs):
super(A,self).__init__(base_ring, basis_keys, prefix=prefix, **
kwargs)

class Element(CombinatorialFreeModule.Element):
pass

class B(A):
def __init__(self, base_ring, basis_keys, prefix='b', **kwargs):
super(B,self).__init__(base_ring, basis_keys, prefix=prefix, **
kwargs)

class C(B):
def __init__(self, shape, prefix='c', **kwargs):
base_ring=PolynomialRing(Integers(), 'q')
super(B,self).__init__(base_ring, shape.standard_tableaux(), prefix=
prefix, **kwargs)

This simplified code works fine. For example,

sage: C(Partition([3,2])).an_element()
2*c[[[1, 2, 5], [3, 4]]] + 3*c[[[1, 3, 4], [2, 5]]] + 2*c[[[1, 3, 5], [2, 4
]]]

Unfortunately my real code does not work, having issues like:

sage: rep=SeminormalRepresentation([2,1]); rep
SeminormalRepresentation([2,1])# seems to work OK
sage: rep.an_element() # try to construct an element
) failed: AttributeError: 
'SeminormalRepresentation_with_category' object has no attribute '_prefix'>
sage: rep(StandardTableau([[1,2],[3]]))
AttributeErrorTraceback (most recent call last)
...
AttributeError: 'SeminormalRepresentation_with_category' object has no 
attribute '_basis_keys'

Does anyone have an idea of what is going wrong. Part of the issue might be 
all of the super calls, but I tried taking though ut and explcitly calling 
the previous class (they are linearly ordered), but this doesn't help.

For anyone feeling masochistic, the full code is at trac:17303 
 (it uses 6.5beta0)

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

On Sat, Nov 15, 2014 at 02:27:06PM -0800, Andrew wrote:
>Ah, right, I agree (he says with a sheepish grin).

Well, the sheepish grin shall be mine for not explaining it right from
the beginning. Thanks for bringing this up as this discussion was
useful to better formalize the rationale for the "Isomorphic" approach.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

> I mean: without knowing something about the semantic of those methods, 
> how do we know that: 
>
> sage: x.antipode() 
>
> will return an element of the algebra, and therefore the result shall 
> be retracted back, whereas: 
>
> sage: x.counit() 
>
> will return an element of the ground field which needs no transformation? 
>
>
Ah, right, I agree (he says with a sheepish grin).
Andrew
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

Dear Andrew,

On Fri, Nov 14, 2014 at 09:02:13PM -0800, Andrew wrote:
>I don't believe this: gap3 is less strongly typed than python and it is
>possible to do this there! :) The natural way to distinguish between
>different bases is using their prefix -- indeed this is effectively
>what chevie does and Eric's manifold's code does.

I mean: without knowing something about the semantic of those methods,
how do we know that:

sage: x.antipode()

will return an element of the algebra, and therefore the result shall
be retracted back, whereas:

sage: x.counit()

will return an element of the ground field which needs no transformation?

You are right, we could run those methods on some element and look at
the parent of the result. So, at the price of a dynamic lookup (which
in my past experience is a source of trouble, but that's another
discussion), we could indeed retrieve about the same information as in
a statically typed language.

So let me rephrase my argument: what we really need to know is which
methods are, or not, preserved by the lift and retract changes of
basis. For a stupid example,

sage: x.coeff(lambda)

is not preserved; so no lifting shall be applied in the first place.

The "Isomorphic" infrastructure is about making the semantic explicit:

- what structure is preserved, or not, by the changes of basis
- which methods are therefore preserved, and how to handle them
  through coercion

As a cherry on the cake this makes it possible to say "F is isomorphic
to G as an algebra, but not as a coalgebra".

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

> Another disadvantage is that, given that methods in Python are not 
> typed, it's impossible to make a difference between methods that 
> return an element of G or of elsewhere, and add coercions as 
> appropriate.  Hence a brute-force approach as above is likely to give 
> out wrong results. I believe we really need to write the wrapper 
> methods by hand. 
>

I don't believe this: gap3 is less strongly typed than python and it is 
possible to do this there! :) The natural way to distinguish between 
different bases is using their prefix -- indeed this is effectively what 
chevie does and Eric's manifold's code does.


> The good news is that there already is infrastructure for this :-) 


Thanks. Will try to understand:)

Andrew 
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

Hi Andrew!

On Tue, Nov 11, 2014 at 03:07:26PM -0800, Andrew wrote:
>This is a good start but it is not enough: essentially the difference
>between what I want and what this does is the same as the difference
>between a vector space isomorphism and an A-module isomorphism. As you
>pointed out, there are limitations if these objects are algebras. The
>same limitations apply to modules because any interesting
>CombinatorialFreeModule will come equipped with endomorphisms, actions
>and other methods. I would like a mechanism for automatically
>transferring these methods to the new module by implicitly invoking the
>coercions above. These methods will be both module methods and module
>element methods and, more generally, algebra and algebra element
>methods.
>I don't think this this should be hard to do within the existing
>framework, and the mechanism should be roughly what you have above.
>After all, this is easy enough to do by hand because if F has a nice
>method then
> 
>sage: G(F(G.an_element()).nice_method())
> 
>transfers the method to G. The trick is to find an efficient, and
>seamless, way of doing this. If F is the original
>CombinatorialFreeModule (with distinguished basis), then the simplest
>hack would be to make __getattr__ in the class for G call the methods
>of F whenever they are not defined. So something like:
> 
>def __getattr__(self, attr):
> try:
> return self(getattr(F(self), atttr))
> except AttributeError:
> pass
> raise AttributeError('{} has no attribute {}\n'.format(self,attr))
> 
>The disadvantage of this approach is that it does not respect
>tab-completion and documentation, so it's probably going to be better
>to play some inheritance tricks.
>In terms of interface, I'd like to set up something like this:
>sage: G=F.new_basis([4,5,6],basis_to_new_basis=phi,
>new_basis_to_basis=psi,...)
>This should accept a subset of the CombinatorialFreeModule arguments
>(for example, basis_keys, prefix, ...), as well as coercions to other
>bases for the module. As I said I'll try and think more about this.
>This would certainly be useful for me. Let me know if it is unlikely to
>be useful for others.

Another disadvantage is that, given that methods in Python are not
typed, it's impossible to make a difference between methods that
return an element of G or of elsewhere, and add coercions as
appropriate.  Hence a brute-force approach as above is likely to give
out wrong results. I believe we really need to write the wrapper
methods by hand.

The good news is that there already is infrastructure for this :-) It
works well in situations like this where there is a single parent one
wants to pull operations from through isomorphisms. Here I am
constructing a free module which is endowed with a Hopf algebra
structure by declaring it as isomorphic to the group algebra of the
symmetric group::

sage: G = SymmetricGroup(3)
sage: F = G.algebra(QQ)
sage: G = CombinatorialFreeModule(QQ, range(6), 
category=HopfAlgebras(QQ).FiniteDimensional().WithBasis().IsomorphicObjects())
sage: G.retract = F.module_morphism(lambda g: G.monomial(G.rank  (g)), 
codomain=G)
sage: G.lift= C.module_morphism(lambda g: F.monomial(G.unrank(g)), 
codomain=F)
sage: G.ambient = lambda : F
sage: G.an_element()^2
17*B[0] + 8*B[1] + 12*B[2] + 6*B[3] + 6*B[4]

This works because, once in the Sage code, it has been explained that
if G is a quotient (more generally a subquotient) of F, then a product
in G can be calculating by lifting to F and retracting back.

The following does not work yet, but it would be easy to add
appropriate methods for coalgebras in Coalgebras.Subquotients:

sage: C.an_element().coproduct()
*boom*

In general every category should eventually specify how its operation
pass to subobjects, quotients, etc.

The thematic tutorial I mentioned previously has a section with an
example like this.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Eric Gourgoulhon]

Hi,

Le mardi 11 novembre 2014 06:11:52 UTC+1, Andrew a écrit :
>
>
> On Tuesday, 11 November 2014 01:08:08 UTC+11, Nicolas M. Thiery wrote:
>>
>>
>> Another approach is to have a single parent, with elements having 
>> potentially several internal representations, and coercions being 
>> handled internally as well. That's what Éric is using in 
>> Sage-Manifolds: 
>>
>> http://sagemanifolds.obspm.fr/ 
>>
>> > put all of this code in a new directory 
>> sage.algebras.iwahoriheckeagebras/ 
>>
>> Hi Nicolas,
>>
>
> Can you give me some more precise pointers as to where to look inside 
> sage-manifolds -- it's quite a large chunk of code.
>

It's in the algebraic part of SageManifolds, posted in ticket #15916 
.
More precisely, this ticket implements the class FiniteRankFreeModule to 
deal with free modules without any distinguished basis. The elements have 
internal representations stored in a dictionary with (key, value) = (basis, 
components w.r.t. basis). An arbitrary number of bases can be introduced. 
Arithmetic operators, like _add_, first search for a basis where both 
elements have some representation (possibly by means of some 
change-of-basis formula) and then add the relevant components. The 
documentation of FiniteRankFreeModule can be found at 
http://sagemanifolds.obspm.fr/doc/tensors_free_module/finite_rank_free_module.html
and some example is described at
http://sagemanifolds.obspm.fr/examples/html/SM_tensors_modules.html
Module morphisms are under development and shall be added to the ticket 
next week. The internal representation of each morphism is a dictionary 
with (key, value) = ((basis_domain, basis_codomain), matrix). In addition, 
there is some coercion between endomorphisms and type-(1,1) tensors. 
Use of the class FiniteRankFreeModule in SageManifolds is illustrated in 
the following diagrams:
http://sagemanifolds.obspm.fr/class_diagrams.html
Best wishes,

  Eric.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Here's a thought for something that could work for elements. Make it a 
wrapper around the element you'd do computations in and have a lazy 
attribute for the converted element, and I think you can use __getattr__ 
(or __getattribute__?) to rediect to the wrapped element and I think this 
works with tab completion...I think there's something like this for 
categories?

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Mark Shimozono]

Andrew and Nicolas,

> But I don't think many -- if any -- are using directly the
> HeckeAlgebraRepresentation class. So feel free to move it around
> and/or refactor it. It would definitely be sensible to have two
> classes in the sage.algebras.hecke_algebras:
> 
>   class IwahoriHeckeAlgebraRepresentation:
>   class 
> AffineIwahoriHeckeAlgebraRepresentation(IwahoriHeckeAlgebraRepresentation):

I used HeckeAlgebraRepresentation extensively to define smash products 
involving Hecke algebras.
I implemented Hecke algebras for unequal parameters,
extended affine Hecke algebras (with the duality isomorphism coercions) which 
is peculiar to affine
root systems, and the double affine Hecke algebra (currently without the full 
duality coercions).
All have several realizations. I implemented smash products, morphisms of 
tensor 
products, grouped tensor products, and used all that stuff extensively.

However my Hecke algebra code assumes generic parameters.
I already regret that because right now I'm really interested in the nilDAHA.

I could use advice on user conventions for setting parameters and such.

Since my goal was the DAHA coercions I had to do lots of multiple realizations,
starting with extended affine Weyl groups and moving up the food chain of Hecke 
algebras.

I am not near to being ready to start merging my code into sage proper
but I should probably do a lot of coordinating with Andrew.

--Mark

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

On 12/11/2014 4:26 am, Nicolas M. Thiery wrote:
 
Is this close enough from what you would want?

sage: F = CombinatorialFreeModule(QQ, [1,2,3])
sage: G = CombinatorialFreeModule(QQ, [4,5,6])
sage: phi = F.module_morphism(lambda i: G.monomial(i+3), codomain=G)
sage: psi = G.module_morphism(lambda i: F.monomial(i-3), codomain=F)
sage: phi.register_as_coercion()
sage: psi.register_as_coercion()

sage: F(G.an_element())
2*B[1] + 2*B[2] + 3*B[3]
sage: G(F.an_element())
2*B[4] + 2*B[5] + 3*B[6]
sage: F.an_element() + G.an_element()
4*B[1] + 4*B[2] + 6*B[3]

 Hi Nicolas,

This is a good start but it is not enough: essentially the difference 
between what I want and what this does is the same as the difference 
between a vector space isomorphism and an A-module isomorphism. As you 
pointed out, there are limitations if these objects are algebras. The same 
limitations apply to modules because any interesting 
CombinatorialFreeModule will come equipped with endomorphisms, actions and 
other methods. I would like a mechanism for automatically transferring 
these methods to the new module by implicitly invoking the coercions above. 
These methods will be both module methods and module element methods and, 
more generally, algebra and algebra element methods.

I don't think this this should be hard to do within the existing framework, 
and the mechanism should be roughly what you have above. After all, this is 
easy enough to do by hand because if F has a nice method then

sage: G(F(G.an_element()).nice_method())

transfers the method to G. The trick is to find an efficient, and seamless, 
way of doing this. If F is the original CombinatorialFreeModule (with 
distinguished basis), then the simplest hack would be to make __getattr__ 
in the class for G call the methods of F whenever they are not defined. So 
something like:

def __getattr__(self, attr):
 try:
 return self(getattr(F(self), atttr))
 except AttributeError:
 pass
 raise AttributeError('{} has no attribute {}\n'.format(self,attr))

The disadvantage of this approach is that it does not respect 
tab-completion and documentation, so it's probably going to be better to 
play some inheritance tricks. 

In terms of interface, I'd like to set up something like this:

sage: G=F.new_basis([4,5,6],basis_to_new_basis=phi, new_basis_to_basis=psi
,...)

This should accept a subset of the CombinatorialFreeModule arguments (for 
example, basis_keys, prefix, ...), as well as coercions to other bases for 
the module. As I said I'll try and think more about this.

This would certainly be useful for me. Let me know if it is unlikely to be 
useful for others.
Andrew




-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Hey Andrew,

My comment wasn't intended as a criticism of the code or of anyone:  it is 
> great that Mike, Nicolas, Christian and others developed this. Nor was it 
> meat as a complaint as I think that our general philosophy is that if you 
> don't like something then discuss and put a patch on trac.
>

I wasn't trying to imply you were, and I'm sorry if I did. I wanted to 
point out that it is a more general Sage issue beyond 
CombinatorialFreeModule, in the sense that it would be the same issues if 
we were trying to do this with (subclasses of) FreeModules, Rings or 
Algebras.

>
> Your second paragraph is really the point that I was making: given an 
> existing CombinatorialFreeModule, which by definition already has at least 
> one basis, it is hard for non-developers to define a new basis that plays 
> well with the existing ones. For me the coercions aren't really the issue, 
> it shouldn't be hard to streamline this and, in any case, to define a new 
> basis for a given module you have to say how it relates to an existing 
> basis.
>

The most basic/simple setup would be different parents (with perhaps some 
common (abstract) base class) with coercions between them and some common 
entry point.

>
> I have used the With Realizations framework quite a bit in my own code 
> and, of course, in the KL-basis machinery. For people developing code  I 
> think this is very workable, but I doubt that a non-developer would get 
> very far with it.
>

   There definitely is an entry barrier. I should also state that the 
WithRealizations framework also allows us to specify when particular 
morphisms are COB's (via the category of the Homset which we can't so 
easily do with ABC's).

>
> Down the track, what I would like to see is a way of *dynamically* adding 
> bases to a CombinatorialFreeModule without these new bases having to be 
> part of the sage source code. For example, it is possible to do this in 
> chevie. From my quick look at the manifold code, it seems that it allows 
> something in this direction. When I have time I'll see if I can find a way 
> of doing this...
>
> Ah I see what you're after. I guess what we could do is have a method to 
an invertible module morphism (on basis) which creates some generic 
subclass of CombinatorialFreeModule which uses this morphism to translate 
(co)multiplication for (co)algebras.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

On Mon, Nov 10, 2014 at 02:47:21PM -0800, Andrew wrote:
>This is probably the most sensible thing to do, and certainly seems to
>be the consensus. Just for fun there are also "degenerate" and
>"non-degenerate" forms of these representations.

I love 0-Hecke :-)

>I'm slightly bemused, however, because I'm fairly sure that, for the
>quadratic relation (T_r-u)(T_r-v), these representations do not exist
>in the literature.

In similar situations, we indeed had to work out a bit the details to
get the code right with completely generic parameters :-)

>Consequently, I suspect that this level of
>generality will never be used. There may also be a speed penalty
>because rational function fields in one variable are probably more
>efficient than function fields in two variables (for type B and higher
>this comment isn't relevant.). On the other hand, allowing a general
>quadratic relation is probably the easiest way to support the two most
>common forms of the quadratic relations: (T_r-q)(T_r+1)=0 and
>(T_r-q)(T_r+q^{-1})=0.

It's only a (potential) problem if the user actually specifies generic
parameters. But in most cases, people will specify their parameters in
their own preferred form, and the calculation will happen within the
field containing those parameters. In short, the code is generic, not
necessarily the calculation.

>(Btw, the same remarks apply to the implementation of the
>KL-bases in sage: what we have is more general than you will find
>in the literature and it automatically works for different
>quadratic relations and for arbitrary coefficient rings provided
>that the KL-bases are well-defined.)

Yup.

>I didn't know about the HeckeAlgebraRepresentation class that is
>defined in this module. I have defined a class,
>IwahoriHeckeAlgebraRepresentation, that is meant to be a generic class
>for defining representations of an Iwahori-Hecke algebra as
>CombinatorialFreeModules. The class in root_system is mainly for affine
>Hecke algebras and it is quite different to what I am doing, but even
>so I am slightly uneasy about introducing a new class that has a
>similar name and functionality to an existing class. It seems to me
>that a better name for the root_system class is
>AffineHeckeAlgebraRepresentation, at least this would help distinguish
>between the two. Perhaps this code would also sit more naturally in the
>new directory sage.algebras.iwahori_hecke_algebras? Is there a better
>name for my class? Does anyone have any thoughts on this? (Particularly
>Anne and Nicolas as this is their code...)

People have started using NSym Macdonald polynomials. But I don't
think many -- if any -- are using directly the
HeckeAlgebraRepresentation class. So feel free to move it around
and/or refactor it. It would definitely be sensible to have two
classes in the sage.algebras.hecke_algebras:

class IwahoriHeckeAlgebraRepresentation:
class 
AffineIwahoriHeckeAlgebraRepresentation(IwahoriHeckeAlgebraRepresentation):

This of course assumes (and fosters!) some common ground between the
two classes. And also assumes that your class is for any Cartan
type. If it's only for finite type, then maybe this should be instead
something like:


class IwahoriHeckeAlgebraRepresentation:
class 
FiniteIwahoriHeckeAlgebraRepresentation(IwahoriHeckeAlgebraRepresentation):
class 
AffineIwahoriHeckeAlgebraRepresentation(IwahoriHeckeAlgebraRepresentation):

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

Dear Andrew, dear Éric,

On Tue, Nov 11, 2014 at 12:33:35AM -0800, Andrew wrote:
>My comment wasn't intended as a criticism of the code or of anyone:

No worry, there was no ambiguity :-)

>Down the track, what I would like to see is a way of dynamically
>adding bases to a CombinatorialFreeModule without these new bases
>having to be part of the sage source code. For example, it is
>possible to do this in chevie.

Is this close enough from what you would want?

sage: F = CombinatorialFreeModule(QQ, [1,2,3])
sage: G = CombinatorialFreeModule(QQ, [4,5,6])
sage: phi = F.module_morphism(lambda i: G.monomial(i+3), codomain=G)
sage: psi = G.module_morphism(lambda i: F.monomial(i-3), codomain=F)
sage: phi.register_as_coercion()
sage: psi.register_as_coercion()

sage: F(G.an_element())
2*B[1] + 2*B[2] + 3*B[3]
sage: G(F.an_element())
2*B[4] + 2*B[5] + 3*B[6]
sage: F.an_element() + G.an_element()
4*B[1] + 4*B[2] + 6*B[3]

There are more details in the Sage-Combinat tutorial «Implementing
Algebraic Structures»:


http://combinat.sagemath.org/doc/thematic_tutorials/tutorial-implementing-algebraic-structures.html#tutorial-implementing-algebraic-structures

There is one main limitation: if F and G are algebras, you need to
define explicitly the product on both sides (possibly trivially by
doing the back and forth with the other side). In MuPAD, the coercion
system did automatically the right thing ...

>From my quick look at the manifold code, it seems that it allows
>something in this direction.

I added Eric Gourgoulhon in CC to point him to this thread.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

On Tuesday, 11 November 2014 17:20:32 UTC+11, Travis Scrimshaw wrote:
>
> Hey Andrew,
>
> One of the things that I don't like about (my understanding of) the 
>> CombinatorialFreeModule approach to modules is that it is very hard for the 
>> (uneducated/unenlightened/unwashed) user to construct their own bases for 
>> modules: To construct a new basis you have to explicitly define it using 
>> realisations hidden deep inside the code, together with the appropriate 
>> coercion maps and I think that the average user won't be able to do this. 
>> It would be nice if this provided a mechanism for doing this.
>>
>>I feel that's somewhat unfair as construct *a* basis is easy, you just 
> need to pass an indexing set. However you want to construct multiple basis, 
> so multiple parents/classes, *and* change of basis coercions between them, 
> the latter part is what takes the work that Sage has default mechanisms for 
> doing so (Parent._coerce_map_from_ or Morphism.register_as_coercion).
>
>That being said, the WithRealizations framework is a way to deal with 
> multiple but not necessarily a "best" basis that can be easily extended. 
> Yet IMO it feels slightly heavy-handed because of the categories involved 
> instead of just using ABC's (there could a reason for this that I'm not 
> seeing). For things with a best basis, I decided to just use the main 
> object as the global entry point with the other basis as methods, see the 
> free algebra and it's PBW basis. This is documented in 
> categories/with_realizations.py, but perhaps a modification/expansion as a 
> thematic tutorial would be beneficial. In either case, the hard work still 
> lies in the defining the COB coercions.
>
>
Hi Travis,

My comment wasn't intended as a criticism of the code or of anyone:  it is 
great that Mike, Nicolas, Christian and others developed this. Nor was it 
meat as a complaint as I think that our general philosophy is that if you 
don't like something then discuss and put a patch on trac.

Your second paragraph is really the point that I was making: given an 
existing CombinatorialFreeModule, which by definition already has at least 
one basis, it is hard for non-developers to define a new basis that plays 
well with the existing ones. For me the coercions aren't really the issue, 
it shouldn't be hard to streamline this and, in any case, to define a new 
basis for a given module you have to say how it relates to an existing 
basis. 

I have used the With Realizations framework quite a bit in my own code and, 
of course, in the KL-basis machinery. For people developing code  I think 
this is very workable, but I doubt that a non-developer would get very far 
with it.

Down the track, what I would like to see is a way of *dynamically* adding 
bases to a CombinatorialFreeModule without these new bases having to be 
part of the sage source code. For example, it is possible to do this in 
chevie. From my quick look at the manifold code, it seems that it allows 
something in this direction. When I have time I'll see if I can find a way 
of doing this...

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Hey Andrew,

One of the things that I don't like about (my understanding of) the 
> CombinatorialFreeModule approach to modules is that it is very hard for the 
> (uneducated/unenlightened/unwashed) user to construct their own bases for 
> modules: To construct a new basis you have to explicitly define it using 
> realisations hidden deep inside the code, together with the appropriate 
> coercion maps and I think that the average user won't be able to do this. 
> It would be nice if this provided a mechanism for doing this.
>
>I feel that's somewhat unfair as construct *a* basis is easy, you just 
need to pass an indexing set. However you want to construct multiple basis, 
so multiple parents/classes, *and* change of basis coercions between them, 
the latter part is what takes the work that Sage has default mechanisms for 
doing so (Parent._coerce_map_from_ or Morphism.register_as_coercion).

   That being said, the WithRealizations framework is a way to deal with 
multiple but not necessarily a "best" basis that can be easily extended. 
Yet IMO it feels slightly heavy-handed because of the categories involved 
instead of just using ABC's (there could a reason for this that I'm not 
seeing). For things with a best basis, I decided to just use the main 
object as the global entry point with the other basis as methods, see the 
free algebra and it's PBW basis. This is documented in 
categories/with_realizations.py, but perhaps a modification/expansion as a 
thematic tutorial would be beneficial. In either case, the hard work still 
lies in the defining the COB coercions.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

On Tuesday, 11 November 2014 01:08:08 UTC+11, Nicolas M. Thiery wrote:
>
>
> Another approach is to have a single parent, with elements having 
> potentially several internal representations, and coercions being 
> handled internally as well. That's what Éric is using in 
> Sage-Manifolds: 
>
> http://sagemanifolds.obspm.fr/ 
>
> > put all of this code in a new directory 
> sage.algebras.iwahoriheckeagebras/ 
>
> Hi Nicolas,
>

Can you give me some more precise pointers as to where to look inside 
sage-manifolds -- it's quite a large chunk of code.

One of the things that I don't like about (my understanding of) the 
CombinatorialFreeModule approach to modules is that it is very hard for the 
(uneducated/unenlightened/unwashed) user to construct their own bases for 
modules: To construct a new basis you have to explicitly define it using 
realisations hidden deep inside the code, together with the appropriate 
coercion maps and I think that the average user won't be able to do this. 
It would be nice if this provided a mechanism for doing this.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Anne Schilling]

On 11/10/14 2:47 PM, Andrew wrote:
> 
> 
> On Tuesday, 11 November 2014 01:08:08 UTC+11, Nicolas M. Thiery wrote:
> 
> On Thu, Nov 06, 2014 at 04:51:40PM -0800, Anne Schilling wrote:
> > Wouldn't it make most sense to use the quadratic relation
> > 
> > $(T_r-q)(T_r-v)=0$
> > 
> > since the other ones can be obtained by appropriate specialization?
> 
> I definitely vote for this as well.
> 
> 
> This is probably the most sensible thing to do, and certainly seems to be the 
> consensus. Just for fun there are also "degenerate" and "non-degenerate" 
> forms of these representations.
> 
> I'm slightly bemused, however, because I'm fairly sure that, for the 
> quadratic relation (T_r-u)(T_r-v), these representations do not exist in the 
> literature.  Consequently, I suspect that this level
> of generality will never be used. There may also be a speed penalty because 
> rational function fields in one variable are probably more efficient than 
> function fields in two variables (for type B and
> higher this comment isn't relevant.). On the other hand, allowing a general 
> quadratic relation is probably the easiest way to support the two most common 
> forms of the quadratic relations:
> (T_r-q)(T_r+1)=0 and (T_r-q)(T_r+q^{-1})=0. (Btw, the same remarks apply to 
> the implementation of the KL-bases in sage: what we have is more general than 
> you will find in the literature and it
> automatically works for different quadratic relations and for arbitrary 
> coefficient rings provided that the KL-bases are well-defined.)
> 
> sage/combinat/root_system/hecke_algebra_representation.py
> 
> 
> I didn't know about the HeckeAlgebraRepresentation class that is defined in 
> this module. I have defined a class, IwahoriHeckeAlgebraRepresentation, that 
> is meant to be a generic class for defining
> representations of an Iwahori-Hecke algebra as CombinatorialFreeModules. The 
> class in root_system is mainly for affine Hecke algebras and it is quite 
> different to what I am doing, but even so I am
> slightly uneasy about introducing a new class that has a similar name and 
> functionality to an existing class. It seems to me that a better name for the 
> root_system class is
> *Affine*HeckeAlgebraRepresentation, at least this would help distinguish 
> between the two. Perhaps this code would also sit more naturally in the new 
> directory sage.algebras.iwahori_hecke_algebras? Is
> there a better name for my class? Does anyone have any thoughts on this? 
> (Particularly Anne and Nicolas as this is their code...)

We needed the code in sage/combinat/root_system/hecke_algebra_representation.py 
to compute the nonsymmetric
Macdonald polynomials. I am ok with renaming it 
AffineHeckeAlgebraRepresentation if it does not
break too much backward compatibility. On the other hand, you are naming your 
class
IwahoriHeckeAlgebraRepresentation, so perhaps that is good enough!?

Anne

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

On Tuesday, 11 November 2014 01:08:08 UTC+11, Nicolas M. Thiery wrote:
>
> On Thu, Nov 06, 2014 at 04:51:40PM -0800, Anne Schilling wrote: 
> > Wouldn't it make most sense to use the quadratic relation 
> > 
> > $(T_r-q)(T_r-v)=0$ 
> > 
> > since the other ones can be obtained by appropriate specialization? 
>
> I definitely vote for this as well. 
>

This is probably the most sensible thing to do, and certainly seems to be 
the consensus. Just for fun there are also "degenerate" and 
"non-degenerate" forms of these representations. 

I'm slightly bemused, however, because I'm fairly sure that, for the 
quadratic relation (T_r-u)(T_r-v), these representations do not exist in 
the literature.  Consequently, I suspect that this level of generality will 
never be used. There may also be a speed penalty because rational function 
fields in one variable are probably more efficient than function fields in 
two variables (for type B and higher this comment isn't relevant.). On the 
other hand, allowing a general quadratic relation is probably the easiest 
way to support the two most common forms of the quadratic relations: 
(T_r-q)(T_r+1)=0 and (T_r-q)(T_r+q^{-1})=0. (Btw, the same remarks apply to 
the implementation of the KL-bases in sage: what we have is more general 
than you will find in the literature and it automatically works for 
different quadratic relations and for arbitrary coefficient rings provided 
that the KL-bases are well-defined.)

sage/combinat/root_system/hecke_algebra_representation.py 
>

I didn't know about the HeckeAlgebraRepresentation class that is defined in 
this module. I have defined a class, IwahoriHeckeAlgebraRepresentation, 
that is meant to be a generic class for defining representations of an 
Iwahori-Hecke algebra as CombinatorialFreeModules. The class in root_system 
is mainly for affine Hecke algebras and it is quite different to what I am 
doing, but even so I am slightly uneasy about introducing a new class that 
has a similar name and functionality to an existing class. It seems to me 
that a better name for the root_system class is 
*Affine*HeckeAlgebraRepresentation, 
at least this would help distinguish between the two. Perhaps this code 
would also sit more naturally in the new directory 
sage.algebras.iwahori_hecke_algebras? Is there a better name for my class? 
Does anyone have any thoughts on this? (Particularly Anne and Nicolas as 
this is their code...)

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

On Thu, Nov 06, 2014 at 04:51:40PM -0800, Anne Schilling wrote:
> Wouldn't it make most sense to use the quadratic relation
> 
> $(T_r-q)(T_r-v)=0$
> 
> since the other ones can be obtained by appropriate specialization?

I definitely vote for this as well. That's what Alain always
recommended to me, and the practicality of the approach was confirmed
by our experience when implementing Non Symmetric Mac Donald
polynomials. See for example:

sage/combinat/root_system/hecke_algebra_representation.py

> > In thinking about this it seems to me that currently there is no
> > framework in sage for dealing with module that has more than one
> > "natural" basis. Is this right? Of course, it is possible to
> > define several different CombinatoriaFreeModules and coercions
> > between them.
>
> Examples of how to handle this might be in
> 
> combinat/ncsf_qsym

Another approach is to have a single parent, with elements having
potentially several internal representations, and coercions being
handled internally as well. That's what Éric is using in
Sage-Manifolds:

http://sagemanifolds.obspm.fr/

> put all of this code in a new directory sage.algebras.iwahoriheckeagebras/

Sounds good to me.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

> On Friday, 7 November 2014 03:56:16 UTC+11, Nicolas M. Thiery wrote:
>
>>
>> This might be the occasion to add a ``cartan type'' for G(r,1,n). 
>>
>
> Implementing these algebras properly would be painful...however, 
> implementing their action on a representation in terms of the natural 
> generators is not, which I guess is what you are suggesting.
>

   I've come across a similar situation with quantum group representations 
(where implementing the actual algebra is difficult compared to 
implementing the representations and the action of natural generators). 
What I ended up decided was best was have methods corresponding to each 
type of generator, and so if/when the algebra is implemented, the action 
would call the corresponding method. I'm very open to a discussion about 
this.

>
> I have realised that attaching the seminormal representations to the Hecke 
> algebras creates a few additional headaches that are associated with the 
> choice of base ring and the choice of parameters of the Iwahori-Hecke 
> algebra. For example, the seminormal representations are naturally defined 
> over Q(q), but the Hecke algebra defined over Z[q,q^-1] also acts on them 
> since this algebra embeds in the algebra over Q(q). Technically, however, 
> the seminormal representation is not a representation for the Hecke algebra 
> defined over Z[q,q^-1].
>
> The question here is whether we should follow the strict mathematical 
> definitions and only allow the Hecke algebras with exactly the same base 
> ring to act or should we be more flexible?  The former is easier in terms 
> of coding whereas the latter is more useful.
>

   I think it depends on how you implement the action; where you could 
perhaps just do the action of a term generator by generator and then 
convert the coefficient into Q(q) and scale the result. Although (I 
believe) the coercion framework would naturally do a pushout construction 
of the Hecke algera over Q(q) and then do the action. I guess what I'm 
saying if you try to make this very mathematically strict, you will likely 
have a fight with the coercion system and it will be different than many 
other parts of Sage.

>
> Then there are other annoyances in that the seminormal representations for 
> the algebras with different quadratic relations, for example 
> $(T_r-q)(T_r+1)=0$, $(T_r-q)(T_r+q^{-1})=0$ or $(T_r-q)(T_r+v)=0$, are all 
> different and, of course, there are several different flavours of 
> seminormal representations. Any suggestions on what we should try and 
> support here would be appreciated.
>

   The biggest thing (to me) is any convention choices that are made are 
well-documented. What about the relations used for the 
IwahoriHeckeAlgebra_nonstandard or some other "idiosyncratic (but 
convenient)" relations?

>
> Another thought that occurs to me, which I don't promise to follow through 
> on, is that I could use the seminormal representation to define Specht 
> modules for these algebras over an arbitrary ring. It is possible to do 
> this using some specialisation tricks. I am not sure how efficient this 
> would be but I suspect that it would be at least as good as my 
> implementation of the Murphy basis in chevie 
>  that I wrote 
> for the Hecke algebras of type A. 
>
> In thinking about this it seems to me that currently there is no framework 
> in sage for dealing with module that has more than one "natural" basis. Is 
> this right? Of course, it is possible to define several different 
> CombinatoriaFreeModules and coercions between them.
>

As Anne said, combinat/descent_algebra.py, or the Iwahori-Hecke algebras. 
What you want to look (grep) for is "WithRealizations".
 

> A final question: where should this code go? Currently the Iwahori-Hecke 
> algebras are defined in sage.algebras and the seminormal matrix 
> representations in sage.combinat. I think the best place might be to put 
> all of this code in a new directory sage.algebras.iwahoriheckeagebras/
>
>I agree with Anne that iwahori_hecke_algebras is a better name for the 
subfolder as I can actually read that without getting cross-eyed. :P 
However I would say it depends on how many new files (python modules) you 
think you'll create. If it's only one or two, I think you can just put it 
in the algebras folder.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Anne Schilling]

Hi Andrew,

> Then there are other annoyances in that the seminormal representations for 
> the algebras with different quadratic relations, for example 
> $(T_r-q)(T_r+1)=0$, $(T_r-q)(T_r+q^{-1})=0$ or
> $(T_r-q)(T_r+v)=0$, are all different and, of course, there are several 
> different flavours of seminormal representations. Any suggestions on what we 
> should try and support here would be appreciated.

Wouldn't it make most sense to use the quadratic relation

$(T_r-q)(T_r-v)=0$

since the other ones can be obtained by appropriate specialization?

> In thinking about this it seems to me that currently there is no framework in 
> sage for dealing with module that has more than one "natural" basis. Is this 
> right? Of course, it is possible to define
> several different CombinatoriaFreeModules and coercions between them.

Examples of how to handle this might be in

combinat/ncsf_qsym

> A final question: where should this code go? Currently the Iwahori-Hecke 
> algebras are defined in sage.algebras and the seminormal matrix 
> representations in sage.combinat. I think the best place might
> be to put all of this code in a new directory 
> sage.algebras.iwahoriheckeagebras/

I think sage.algebras.iwahori_hecke_algebras might be best. But then 
iwahori_hecke_algebra.py
should probably also be moved.

Best,

Anne

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

On Friday, 7 November 2014 03:56:16 UTC+11, Nicolas M. Thiery wrote:

>
> This might be the occasion to add a ``cartan type'' for G(r,1,n). 
>

Implementing these algebras properly would be painful...however, 
implementing their action on a representation in terms of the natural 
generators is not, which I guess is what you are suggesting.

I have realised that attaching the seminormal representations to the Hecke 
algebras creates a few additional headaches that are associated with the 
choice of base ring and the choice of parameters of the Iwahori-Hecke 
algebra. For example, the seminormal representations are naturally defined 
over Q(q), but the Hecke algebra defined over Z[q,q^-1] also acts on them 
since this algebra embeds in the algebra over Q(q). Technically, however, 
the seminormal representation is not a representation for the Hecke algebra 
defined over Z[q,q^-1].

The question here is whether we should follow the strict mathematical 
definitions and only allow the Hecke algebras with exactly the same base 
ring to act or should we be more flexible?  The former is easier in terms 
of coding whereas the latter is more useful (but technically incorrect).

Then there are other annoyances in that the seminormal representations for 
the algebras with different quadratic relations, for example 
$(T_r-q)(T_r+1)=0$, $(T_r-q)(T_r+q^{-1})=0$ or $(T_r-q)(T_r+v)=0$, are all 
different and, of course, there are several different flavours of 
seminormal representations. Any suggestions on what we should try and 
support here would be appreciated.

Another thought that occurs to me, which I don't promise to follow through 
on, is that I could use the seminormal representation to define Specht 
modules for these algebras over an arbitrary ring. It is possible to do 
this using some specialisation tricks. I am not sure how efficient this 
would be but I suspect that it would be at least as good as my 
implementation of the Murphy basis in chevie 
 that I wrote 
for the Hecke algebras of type A. 

In thinking about this it seems to me that currently there is no framework 
in sage for dealing with module that has more than one "natural" basis. Is 
this right? Of course, it is possible to define several different 
CombinatoriaFreeModules and coercions between them.

So, if you think of rep as a module, this could be: 
>
> rep.action(a, r) 
>
> Then we can optionally setup the following as syntactic sugar: 
>
> a*r or r*a 
>
>
I'll implement both. I have the second alternative working already, 
although some necessary sanity checks relating to the questions above are 
missing.

A final question: where should this code go? Currently the Iwahori-Hecke 
algebras are defined in sage.algebras and the seminormal matrix 
representations in sage.combinat. I think the best place might be to put 
all of this code in a new directory sage.algebras.iwahoriheckeagebras/

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

``_rmul_`` and ``_lmul_`` (it's the module element (i.e., ``self``) on the 
right or left respectively), and (somewhat unfortunately) I think you need 
to also inherit from ModuleElement (or copy the ``__mul__`` method).

>
> Or is it preferred to use ``_acted_upon_`` (see in 
> CombinatorialFreeModule)?
>

Thanks Travis. This is what I tried before I asked yesterday but I couldn't 
get it to work. The issue is that there is no multiplication defined on 
elements in a representation. In any case I have something working using 
sage.categories.action.Action.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

On Thu, Nov 06, 2014 at 01:04:30AM -0800, Andrew wrote:
>Yes, you're right, this is almost certainly on the roadmap. In any
>case, as Nicolas and Travis are both in favour I'll try and make time
>to properly wrap and prettify the code, create a ticket and push it to
>git and trac or comments and review. I'll first have to think a little
>harder about the best interface.I will probably end up implementing the
>seminormal representations simultaneously for the symmetric groups and,
>more generally, he Hecke algebras of type A, B, ..., G(r,1,n) as in the
>end thee are all the same.

Nice! This might be the occasion to add a ``cartan type'' for G(r,1,n).

>Yes this is a good idea, but now there are some questions.
> 1. Left modules or right modules, or both? (My current methods you can
>interpret as either.)

I would say both if there is no complexity overhead:

G.representation(..., side="left"/"right")

> 2. What is the best syntax for the action?
>The first question is not a big deal. For the second the following is
>probably the most natural answer::
>sage: A=SymmetricGroupAlgebra(QQ,3)
>sage: rep=SeminormalRepresentation([2,1])
>sage: a=A.an_element(); a
>2*[1, 2, 3] + 2*[1, 3, 2] + 3*[2, 1, 3]
>sage: r=rep.an_element(); r
>2*f(1,2/3) + 2*f(1,3/2)
>sage: a*r  # left action
>???
> 
>Using a*r for the left action, and r*a for the right action, seems to
>be the natural syntax. Is there already a mechanism in place for doing
>this? I assume that there is, but I don't know it. Can some one point
>me in the right direction?

I would do like in math: define first a notation which makes the
representation explicit, and then, if there is an ambiguity from the
context define a shorthand.


So, if you think of rep as a module, this could be:

rep.action(a, r)

Alternatively, if you think of rep as a representation, this could be:

rep(a)(r)

Then we can optionally setup the following as syntactic sugar:

a*r or r*a

However multiplication is already overloaded quite some, so it's not
even clear we want this as a default.

In all my semigroup representation code, I have used rep.action(a,r)
systematically. One further advantage is that the notation is
side-agnostic; so we can write code on top of it that does not depend
on whether we have a left or right action.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

``_rmul_`` and ``_lmul_`` (it's the module element (i.e., ``self``) on the 
right or left respectively), and (somewhat unfortunately) I think you need 
to also inherit from ModuleElement (or copy the ``__mul__`` method).

Or is it preferred to use ``_acted_upon_`` (see in CombinatorialFreeModule)?

Best,
Travis


On Thursday, November 6, 2014 1:04:30 AM UTC-8, Andrew wrote:
>
> Dear Bruce and Travis,
>
> Thanks for your suggestions. I realised after reading your posts that a 
> much better way to construct my coefficient ring is to start with a 
> polynomial ring over Q(q) with n+1 indeterminants  and then quotient out by 
> a suitable ideal. This constructs the ring directly and the factorisation 
> properties that I wanted are now automatic:
>
> sage: SeminormalRepresentation([2,2]).tau_character(1,2)
> 1/q*I*r3
>
>
> Just a short answer for now: it's been in the TODO list for a while to 
>> have representation matrices for the Hecke algebra (there might be a 
>> ticket about this, and almost certainly a note in the road map). So 
>> progress in this direction is surely welcome, especially if this can 
>> be done uniformly for symmetric groups versus hecke algebras and type 
>> A versus generic type. 
>>
>
> Yes, you're right, this is almost certainly on the roadmap. In any case, 
> as Nicolas and Travis are both in favour I'll try and make time to properly 
> wrap and prettify the code, create a ticket and push it to git and trac or 
> comments and review. I'll first have to think a little harder about the 
> best interface.I will probably end up implementing the seminormal 
> representations simultaneously for the symmetric groups and, more 
> generally, he Hecke algebras of type A, B, ..., G(r,1,n) as in the end thee 
> are all the same.
>
>
>> By the way, this could be an occasion to make those methods of the 
>> symmetric group / hecke algebra. Something like: 
>>
>> sage: SymmetricGroup(5).representation([3,2], "seminormal") 
>>
>>
> Yes this is a good idea, but now there are some questions.
>
>1. Left modules or right modules, or both? (My current methods you can 
>interpret as either.)
>2. What is the best syntax for the action?
>
> The first question is not a big deal. For the second the following is 
> probably the most natural answer::
> sage: A=SymmetricGroupAlgebra(QQ,3)
> sage: rep=SeminormalRepresentation([2,1])
> sage: a=A.an_element(); a
> 2*[1, 2, 3] + 2*[1, 3, 2] + 3*[2, 1, 3]
> sage: r=rep.an_element(); r
> 2*f(1,2/3) + 2*f(1,3/2)
> sage: a*r  # left action
> ???
>
>
> Using a*r for the left action, and r*a for the right action, seems to be 
> the natural syntax. Is there already a mechanism in place for doing this? I 
> assume that there is, but I don't know it. Can some one point me in the 
> right direction?
> Andrew
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

Dear Bruce and Travis,

Thanks for your suggestions. I realised after reading your posts that a 
much better way to construct my coefficient ring is to start with a 
polynomial ring over Q(q) with n+1 indeterminants  and then quotient out by 
a suitable ideal. This constructs the ring directly and the factorisation 
properties that I wanted are now automatic:

sage: SeminormalRepresentation([2,2]).tau_character(1,2)
1/q*I*r3


Just a short answer for now: it's been in the TODO list for a while to 
> have representation matrices for the Hecke algebra (there might be a 
> ticket about this, and almost certainly a note in the road map). So 
> progress in this direction is surely welcome, especially if this can 
> be done uniformly for symmetric groups versus hecke algebras and type 
> A versus generic type. 
>

Yes, you're right, this is almost certainly on the roadmap. In any case, as 
Nicolas and Travis are both in favour I'll try and make time to properly 
wrap and prettify the code, create a ticket and push it to git and trac or 
comments and review. I'll first have to think a little harder about the 
best interface.I will probably end up implementing the seminormal 
representations simultaneously for the symmetric groups and, more 
generally, he Hecke algebras of type A, B, ..., G(r,1,n) as in the end thee 
are all the same.


> By the way, this could be an occasion to make those methods of the 
> symmetric group / hecke algebra. Something like: 
>
> sage: SymmetricGroup(5).representation([3,2], "seminormal") 
>
>
Yes this is a good idea, but now there are some questions.

   1. Left modules or right modules, or both? (My current methods you can 
   interpret as either.)
   2. What is the best syntax for the action?

The first question is not a big deal. For the second the following is 
probably the most natural answer::
sage: A=SymmetricGroupAlgebra(QQ,3)
sage: rep=SeminormalRepresentation([2,1])
sage: a=A.an_element(); a
2*[1, 2, 3] + 2*[1, 3, 2] + 3*[2, 1, 3]
sage: r=rep.an_element(); r
2*f(1,2/3) + 2*f(1,3/2)
sage: a*r  # left action
???


Using a*r for the left action, and r*a for the right action, seems to be 
the natural syntax. Is there already a mechanism in place for doing this? I 
assume that there is, but I don't know it. Can some one point me in the 
right direction?
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Nicolas M. Thiery]

Dear Andrew,

On Mon, Nov 03, 2014 at 07:23:32PM -0800, Andrew wrote:
>Sorry, this is a longish post...

Just a short answer for now: it's been in the TODO list for a while to
have representation matrices for the Hecke algebra (there might be a
ticket about this, and almost certainly a note in the road map). So
progress in this direction is surely welcome, especially if this can
be done uniformly for symmetric groups versus hecke algebras and type
A versus generic type.

By the way, this could be an occasion to make those methods of the
symmetric group / hecke algebra. Something like:

sage: SymmetricGroup(5).representation([3,2], "seminormal")

As for speed: do you think the limitation comes from the cost of the
arithmetic in the base field, or from the linear algebra?

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Making code for some seminormal representations faster

[Andrew]

Sorry, this is a longish post...there are some questions at the end that 
roughly come down to can you see how to improve my code. If you don't care 
about representations of symmetric groups and Hecke algebras, or about 
CombinatorialFreeModules, then you may want to stop reading now!

Some time ago Franco (and possibly others?), wrote some code for 
constructing the irreducible matrix representations of the symmetric groups 
in characteristic zero. Recently I have been looking at the corresponding 
representations for the Hecke algebra of the symmetric group and the 
questions that I am interested in relate to how these representations 
restrict to the subalgebra of the Hecke algebra corresponding to the 
alternating group. The easiest way to answer this question is to work with 
slightly different matrix representations over slightly horrible rings 
where these representations split when restricted to the alternating Hecke 
algebra.

I have written some code that implements all of this in sage (see 
attached). For the symmetric groups this is roughly equivalent to the 
existing code in sage.combinat.symmetric_group_representations *except* 
that the existing computes the matrices that give the action for the 
symmetric groups on the ordinary irreducible representations whereas my 
code defines a `CombinatorialFreeModule` for computing inside these modules 
for the Hecke algebras (so the symmetric group is a special case):

sage: rep=SeminormalRepresentation([3,2,1]); rep
SeminormalRepresentation([3,2,1])
sage: rep([[1,2,3],[4,5],[6]]).T(1)
q*f(1,2,3/4,5/6)
sage: rep([[1,2,3],[4,5],[6]]).T(1,2)
q^2*f(1,2,3/4,5/6)

Currently the code is geared towards restricting to the alternating Hecke 
algebras (meaning that it works over quite horrible rings) but it would be 
easy enough to make it use nicer rings for the symmetric groups and their 
Hecke algebras. 

If people think this is interesting I would be happy to include this code 
in sage, however, the main reason that I am writing is because the code is 
much slower than I expected (I have similar code written in gap 3 that is 
faster). In addition, the output is quite horrible. I am fairly sure that 
the reason why the code is slow, and certainly the reason for the horrible 
output, is because of the rings that I have work over. If people are 
interested in having this ins sage then I'll make it possible to choose 
nicer rings (here the code should also be much faster).

To define the rings that I want to work over I start with the Laurent 
polynomial ring `Z[q,q^{-1}]` and then I adjoin the inverses and square 
roots of the Gaussian polynomials `[k]=1+q^2+q^4+\dots+q^{2k-2}`, for `1\le 
khttp://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
from sage.combinat.free_module import CombinatorialFreeModule
from sage.misc.cachefunc import cached_method
from sage.rings.fraction_field import FractionField_generic
from sage.rings.integer_ring import IntegerRing
from sage.rings.rational_field import RationalField
from sage.rings.polynomial.laurent_polynomial_ring import LaurentPolynomialRing
from sage.rings.polynomial.polynomial_ring import polygen

class SeminormalRepresentation(CombinatorialFreeModule):
r"""
Implement a particular seminormal representation of the Iwahori-Hecke algebras of type A that 
restricts well to the alternating group. This module has a basis $\{f_t\}$ indexed by
the set of standard tableaux of the corresponding shape. If $1\le r\le n$
then the action of `T_r` on the basis element `f_t` is given by

.. MATH::

   f_t T_r = \frac{-q^{-1}}{[d]}f_t + \alpha_d f_s

where $d=c_r(t)-c_{r+1}(t)$  is the axial distance from $r$ to $r+1$ in `t` and

.. MATH::

   \alpha_d = \begin{cases}
 \frac{\sqrt{-1}\sqrt{[d+1]}\sqrt{[d-1]}}{[d]},&\text{if }d>0,\\
-\frac{\sqrt{-1}\sqrt{[-d+1]}\sqrt{[-d-1]}}{[d]},&\text{if }d<0.
   \end{cases}

The whole point of choosing this particular basis is that if the module
is indexed by a self-conjugate partition then it splits when it is
restricted to the alternating Hecke algebra.

Finally, it should be mentioned that the particular Iwahori-Hecke algebra
being used here is the one with quadratic relations

.. MATH::

(T_r - q)(T_r + q^{-1}) = 0, \qquad\text{ for }1\le r=0 else -self.q**(2*d)*self.__quantum_integer[-d]

def _quantum_integer_root(self,d):
r"""
Return the square root of the quantum integer `[d]_{q^2}`. These square
roots are chosen so that `\sqrt{[-d]}=\sqrt{-1}q^d\sqrt{[d]` if `d<0`.

EXAMPLES::

sage: SeminormalRepresentation([3,2])._quantum_integer_root(3)
r3
sage: SeminormalRepresentation([3,2])._quantum_integer_root(-3)
((q^-3)*r3)*I

"""
return self.__quantum_integer_root[d] if d>=0 else self.I*self.q**d*self.__quantum_integer_roo