Re: [sage-combinat-devel] Making code for some seminormal representations faster
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 T(1),...,T(n-1) 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
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 repr(sage.algebras.iwahori_hecke_algebras. 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, 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 http://trac.sagemath.org/ticket/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
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 repr(sage.algebras.iwahori_hecke_algebras. 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 http://trac.sagemath.org/ticket/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
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 repr(sage.algebras.iwahori_hecke_algebras.iwahori_hecke_algebra_repre 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 nthi...@users.sf.net 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
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
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
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 nthi...@users.sf.net 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
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
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
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 http://trac.sagemath.org/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
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 nthi...@users.sf.net
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
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
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 nthi...@users.sf.net 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
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 nthi...@users.sf.net
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
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
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
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
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 nthi...@users.sf.net 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
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
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
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
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
``_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
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 nthi...@users.sf.net 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
``_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
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
http://webusers.imj-prg.fr/~jean.michel/chevie/index.html 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
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
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 nthi...@users.sf.net 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
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
kn`, where `n` is the size of the partition that indexes the
representation. The only way that I found to construct this ring in sage is
by recursively adjoining more and more square roots to the Laurent
polynomial ring (in gap I hacked their polynomial code to do roughly the
same thing, but somehow it works better). Sadly because my rings are
iterated extensions sage is no longer able to cancel common factors in the
denominators and numerators of the polynomials that arise, so I get things
like
sage: SeminormalRepresentation([2,2]).tau_character(1,2)
(((-1 - 2*q^2 - q^4)*r3)*I)/(-q - 2*q^3 - q^5)
Nothing that I have tried convinces sage to cancel the common factor of
`(q^2-1)^2` here. What I am actually computing, `tau_character`, is a
twisted character value that is the interesting part of the character of
the alternating group -- and `r3` is shorthand for the square root of
`[3]=1+q^2+q^4`. Of course, this actual character value is just `q*I*r3`
but I can't see how to convince sage to do this simplification for me. (In
fact, I alerady know these character values in general, but that's another
story.)
So here are my questions:
1. Is there a better way to define the rings that I need to work over?
2. Is there a way to make sage cancel common factors in expressions like
the one above?
3. Is there anything obviously inefficient in my code? For example,
would it be better to define the element method `T` as a linear
endomorphism?
4. Is there interest in putting this into sage?
Apologies for the long post, especially as I know that this will be of
limited interest AND because I know that asking people to wade through my
code is a huge ask. For what it's worth, the code is fully documented, and
doctested, and the actual code is not so long.
Cheers,
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.
from sage.combinat.free_module
