Dear David and Nicolas,
On Mar 14, 9:42 am, David Kohel <drko...@gmail.com> wrote:
> I would suggest that the choice of basis (or generators) should
> be an intrinsic part of the algebra's representation and interface.
> Different representations imply different (but possibly equal, even
> canonically equal) algebras.
-1: If you are talking about an algebra with a single basis/set of
generators then I agree. Here, however, we are talking about algebras
which have many useful bases. The representation of each basis should
be `intrinsic to that basis` but the algebra itself, and in particular
elements of the algebra, need not have a canonical representation.
> Compare free modules and polynomial rings:
>
> sage: V = FreeModule(QQ,2)
> sage: B = V.basis()
> sage: B[0]
> (1, 0)
> sage: U = V.submodule_with_basis([ V([1,2]), V([0,1]) ])
> sage: U == V
> True
> sage: U.basis() == V.basis()
> False
Given that this is the way that bases currently work in sage this
suggests 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);
> sage: H = HeckeAlgebra(R, W, q1, q2, basis='hecke')
> sage: T = H.basis()
> sage: T[(1,2,1)] == H.gen((1,2,1))
> True
>
> I think also the parent of T[(1,2,1)] should be H and not the set T;
Yes, I agree.
> Or one can create a class of homomorphisms and set up an isomorphism
> between a Hecke algebras in one basis to one in the other.
<SNIP>
> Possible drawbacks: if H and A are expensive to create, and cache
> important information, this information will not be simultaneously
> available to both rings and may have to be recalculated (or some
> sophisticated global caching would be required).
>
> Advantages: The basis and/or generators are well-defined for each
> ring.
> It is clear when one passes from one representation to another. One
> representation of an object does not try to pretend to be the other.
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 (btw, can some one please tell me where the inner
workings of sage's coercion model are documented s I need to
understand this). 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).
> It is probable that one wants a different print function for each different
> representation and access to implementation data such as the support
> (= basis elements with non-zero coefficients) and coefficients are
> well-defined.
Yes, elements/representations need to be able to control printing,
addition, multiplication, ... themselves as there may be (algorithmic)
shortcuts for particular representations. There should, however, be
reasonable defaults which you can override.
> But the proliferation of the possible short-hands, H.YB, H.KL, H.C,
> depending on the particular presentation of the algebra, leads me to
> believe that this is not the way to go.
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.
> Other comments:
>
> > - Syntactically distinguishing different operations to prevent any
> > ambiguity.
> > Namely: what should T(2) mean:
> > - The integer 2 in ZZ, embedded via the canonical morphism into T?
> > - The 2nd generator of the Hecke algebra?
> > (such ambiguities have lead to maintenance and debugging nightmares)
>
> Indeed, for a unital algebra A and integer n, the value A(n) must be
> the integer n as an element of A.
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?
> > Decisions to be taken:
>
> > (I) Syntax to access the Hecke algebra in the T basis:
>
> > Choices:
> > (1) H.T
> > (2) H.T()
> > (3) ???
>
> > In MuPAD, we were using (1), which is nice and short.
+1 -- I think that expressions like T(1,2,1) C(1,2,1), where C=a KL-
basis, are essential for the Iwahori-Hecke algebras. Exactly how T()
is defined relative to H gives, I hope, enough leeway to make this
possible.
> I would even ask, what homomorphisms (of sets, monoids, etc.)
> apply to T? If it is not typically needed as a structure with
> morphisms, and one usually just creates one element at a time,
> then (2) H.T a function, with H.T(n) the call to this function, is
> preferable. Since these are the ring generators, however, this
> should be accessed via H.gen(n).
Basis elements and generators, in general, are quite different
concepts. In many cases, like here, the generators are also basis
elements -- provided that you use the right basis. If a basis element
also happens to be one of the "natural" generators for the algebra
thenI don't think that necessarily implies that the only way to access
this element is via H.gen(n) -- btw, should this be H.generator(n)? In
thiis case I think that H.T(i) and H.generator(i) should both be
legal.
> > (II) Syntax to access the basis itself:
>
> > Choices:
> > (1) A.basis()
> > (2) A.basis
>
> (1)
A.basis('basis name') !
>
> > (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.
> > (2) Extend B so that B[1], B[2,1,2], B[[2,1,2]] do the expected thing
>
> > Note: with appropriate shortcuts W and s defined previously,
> > one can readily write B[W([2,1,2])] or B[ s[2] * s[1] * s[2] ]
>
> > Ah. Darn. W([3,1,2]) could be ambiguous with creating an
> > element of W from a permutation. Same thing with B[[3,1,2]].
> > Then, what about extending the s = W.simple_reflections()
> > shortcut to allow for s[2,1,2] = s[2]*s[1]*s[2]. This would
> > be consistent with multiplicative basis for symmetric
> > functions, and would allow for B[ s[3,1,2] ] (the reduced
> > word 312) vs B[ [3,1,2] ] (the permutation 312).
Side comment: permutations in sage appear to me to be very cumbersome
and inefficient to use. Is there a good design reason to use words
[i_1,...,i_n]?
> > Votes:
>
> Here B is a basis, right? I would vote for one and only one index set
> for a basis, again with the flexibility to create the same mathematical
> object with different generator sets.
Having both B[1] and B[s[1]] is nice but not a necessity especially it
it creates too much dispatch overhead...
> > (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)
> > (4) Define a shorthand gadget, so that the user can do something like:
I think I'm confused here because I thought that the coercion
mechanism would make things H.T( H.C(w) ) work automatically behind
the scenes.
In any case, whether or not the class provides such shorthands the
users is always free to define them themselves.
Cheers,
Andrew
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
