Dear Andrew,
I hope my previous message clarified the discussion. Let me know if
there are some unanswered parts to your message.
On Fri, Mar 13, 2009 at 07:31:22PM -0700, Andrew Mathas wrote:
<SNIP>
> another possibility for the syntax for algebras with many
> bases:
> sage: H = HeckeAlgebra(R, W, q)
> sage: T = H.basis('T')
> sage: T(1,2,1)
> In fact, this close to the mechanism that we introduced for accessing
> the many different bases of the Hecke algebras in chevie where we
> used
> Basis(H,'T')(1,2,1);
-1 because this does not support introspection (e.g. H.<TAB> to find
all the available bases).
Oh, I have a doubt. What does H.basis('T') models for you:
- The Hecke algebra with elements expanded in the T basis
- The T basis itself
> This is one advantage of the H.basis('T'), H.basis("C'"), H.basis
> ('Murphy'), .. approach. You can define your own shortcuts if you want
> them and otherwise they are all accessed in a uniform way.
Is there any difference with H.T() / H.C() / H.murphy() ?
> I vote for having one algebra and many different representations of
> its elements so that the elements in different bases can easily
> access any cached information in the algebra. In other words I am
> drawing a strong distinction between the algebra and the elements of
> the algebra, which may have many different representations with
> coercion maps between. The algebra class should be a container for
> the representation independent information and the element classes
> should hold the representation dependent data. Thus each element
> class would have a unique representation, indexing set etc. Note
> also that generating sets may not make sense for every basis (the
> full basis is, of course, a set of generators but not a useful set
> in general).
<SNIP>
> Yes, elements/representations need to be able to control printing,
> addition, multiplication, ... themselves as there may be (algorithmic)
> shortcuts for particular representations.
Does the layout presented in my previous e-mail satisfy your
requirements?
> There should, however, be reasonable defaults which you can
> override.
I did not elaborate on this, but that's what the category I mentioned
will be about. In fact, for symmetric functions, there will be a
hierarchy of such categories:
- SymmetricFunctions(QQ)
- SymmetricFunctionsOnMultiplicativeBasis(QQ)
- SymmetricFunctionsOnMultiplicativePrimitiveBasis(QQ)
See (with the patches applied) sage/combinat/ncsf/ncsf.py for a draft
of this in the case of non commutative symmetric functions.
> (btw, can some one please tell me where the inner workings of sage's
> coercion model are documented s I need to understand this)
http://wiki.sagemath.org/coercion
> I agree that A(scalar) should just embed embed scales into the
> algebra. I'm not sure how coercion works in sage, but it is is
> possible the meaning of T(1) should depend on T. If T expects it's
> arguments to be a sequence of integers -- for example, in the Iwahori-
> Hecke algebra case I think that this is essential given the typical
> calculations -- then T(1) should map to whatever T() thinks it should
> be. If 1 has no special meaning for T() then it should default to A
> (1). Is this feasible?
Feasible, but not a robust thing. That's ok for magical shorthands,
but not for the main code.
> > > (III) Additional short hands:
> > > There are some choices which are not necessarily incompatible.
> >
> > > (1) Extend A so that A(w) and A([2,1,2]) build the basis element
> > > indexed by the corresponding Weyl group element.
> >
> > I would suggest supporting A(x) if (and only if) x is canonically
> > identified with the fixed choice of basis or generator set. Supporting
> > both for
> > a single representation of the same ring creates ambiguity.
>
> +1 It is canonical: everything is defined in terms of a fixed choice
> of root/simple reflections.
Ok, I should have been specific about what is "canonical". Yes, of
course, A((2,1,2)) is well defined. But in Sage (and MuPAD) coercions
are called canonical/natural if the diagram of all coercions is
commutative. This is not the case here. Let me explain this in the
case of symmetric functions. The following coercion diagram is not
commutative:
partitions --> schur
\ |
\ |
_| \ /
elementary
Because s([3,2,1]) is not the same symmetric function as s( e([3,2,1]) )
> > > (3) Extend A so that A[w], A[2,1,2], A[[2,1,2]] do the expected
> > > thing.
>
> -1: I vote for a clear distinction between the algebra and the
> particular representation of its element (classes)
Here, A is the Hecke algebra with elements expressed in the T
basis. Does this clarification change your vote?
Best,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
