[GAP Forum] Modules over general and not so general algebras

Max Horn max at quendi.de
Wed Feb 20 15:06:25 GMT 2013


Dear Johannes,

On 01.02.2013, at 15:38, Johannes Hahn wrote:

> Hi everyone.
> 
> Is there an elegant way to implement (finite-dimensional) modules over my favorite algebra? My algebra is finite dimensional and I would GAP tell this if it needs to know, but I don't want to spell out an explicit basis and structure constants for the algebra. (More to the point: I work with Hecke algebras and they get way to big for this, if the Coxeter group is big, say E_7, E_8)
> 
> I do not actually need the algebra, I just want to do some computations with the matrices of the representation. There seems no way to define an algebra by generators and relations because GAP seemingly wants to do some calculations and of course this goes wrong in the general case and even in my special case GAP doesn't know that there are normalforms for the elements of my algebra etc. (And I cannot find a way to tell GAP this)

If you know how to compute normal forms for your algebras effectively, you could implement your own algebra(-with-one) type and teach GAP about that. But I am not sure if that is really what you wanted to hear ;-)..


> 
> The next best thing would be to just forget the relations for a moment and think of the modules as algebra morphisms from the free algebra on the (small) set of generators into a full matrix algebra. If you have that, one could implement a filter that checks the defining relations of my favorite algebra for such morphisms manually.
> GAP knows free algebras and it knows matrix algebras and it has an operation for defining algebra morphisms by their images, but interestingly, even this does not work.
> 
> If I just try to get the morphism Q<x,y> \to Q, x \mapsto 1, y\mapsto 1 doing this:
> > F:=FreeAssociativeAlgebraWithOne(Rationals,2);
> <algebra-with-one over Rationals, with 2 generators>
> > f := AlgebraHomomorphismByImages(F,FullMatrixAlgebra(Rationals,1), GeneratorsOfAlgebraWithOne(F),[ [[1]], [[1]] ]);
> then GAP enters an infinite loop for some reason.

The reason is that it wants to verify that what you specified there is really an algebra homomorphism (which is sensible), but it then attempts to compute a "nice" presentation of the algebra F as a module... which is of course not sensible, as that module would be infinite dimensional. So I'd consider this a bug, or perhaps a missing feature. This is essentially due to the fact that GAP is lacking a lot of (sometimes even relatively basic) functionality when it comes to algebras other than those defined by a structure constant table (sct). :-(.

One can avoid this by using the NC variant:

gap>  f := AlgebraHomomorphismByImagesNC(F,FullMatrixAlgebra(Rationals,1), GeneratorsOfAlgebraWithOne(F),[ [[1]], [[1]] ]);
[ (1)*x.1, (1)*x.2 ] -> [ [ [ 1 ] ], [ [ 1 ] ] ]


But that doesn't quite help, as it still does not know how to actually compute the image. The following code snippet should fix this. Also note that you may actually want to use AlgebraWithOneHomomorphismByImagesNC (see also my other email to Sandeep for more about that),

InstallMethod( ImagesRepresentative,
    FamSourceEqFamElm,
    [ IsAlgebraHomomorphism, IsElementOfFreeMagmaRing ],
    function( hom, elm )
    local mgi;
    mgi := MappingGeneratorsImages(hom);
    return MappedExpressionForElementOfFreeAssociativeAlgebra( elm, mgi[1], mgi[2] );
    end );

But note that this is a hack: It does not verify that the generators you specified when defining the homomorphism are indeed the canonical generators (returned by GeneratorsOfAlgebraWithOne()) of F. But with some work, it should be possible to enhance GAP to use something like that above. I'll log a feature request for this all in the GAP tracker.



> This behaviour is completely mysterious to me. Why on earth would GAP even consider to do *any* computation in that situation? There is exactly nothing else to know about a general algebra morphism on a free algebra other than the data that already has been given. The only thing to do here is to take the input data, wrap it into an object, set some filters to true and return that object.
> Why does GAP try to compute anything here instead of just giving me my morphism so I can start working with it?

Well, because GAP is just a dumb computer program, and nobody has so far taught it about this particular property of free algebras and morphisms from them... in other words: because nobody implemented this so far... ;-). But I do agree that this is irritating and somewhat frustrating. In fact, I have been bitten by similar problems before.

BTW, in a somewhat tangential note: It would be nice if e.g. the GBNP package (which provides non-commutative Groebner basis computations) could be enhanced as to install suitable methods for fp rings / algebras -- with GBNP, it is actually possible to compute bases of fp algebras in many cases, and compute with them without providing structure constant tables -- except that doing so produces highly unreadable code, because no methods for things like \+, \* etc. are installed :-(.

> 
> Should there be a compelling reason for GAP to behave this way (although I really can't think of any...), then my question immediatly changes into: What is an elegant way to implement matrix representation of Hecke algebras without having to tell GAP an explicit basis and structure constants for the algebra?
> 
> Right now I'm just working with plain records to store information about the representation but this seems very inelegant to me. There are no "real" objects, no types, no possibility for method-selection based on additional information... (and I can't figure out how to implement Hecke-Matrix-Representation objects for myself... I'm not sure yet if GAP really behaves differently than the manual claims or if I'm just to stupid to read the manual correctly.)

If the manual truly claims that the above should work, then this is a mistake in the manual, and should be corrected (until such functionality is actually implemented, at least). Any pointers to such incorrect or at least misleading parts of the manual would be greatly appreciated!



Cheers,
Max


More information about the Forum mailing list