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 loo
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).
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 initi
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
>
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...@googleg
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 c
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
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
> 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 t
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 effective
> 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
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 yo
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 i
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 wit
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 IwahoriHeckeAlgebraR
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_m
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 t
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 bemuse
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 Combi
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 t
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 de
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:
>
>
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$
> >
>
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 spec
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 m
> 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
> gen
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
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 no
``_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
> CombinatorialFreeMo
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
``_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)?
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
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
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 a
34 matches
Mail list logo
