The RadicalOfModuleInclusion hom cannot be applied to elements of RadicalOfModule

[fingolfin]

gap> Q:=Quiver(3,[[1,2,"a"], [2,3,"b"]]);
<quiver with 3 vertices and 2 arrows>
gap> kQ:=PathAlgebra(Rationals, Q);
<Rationals[<quiver with 3 vertices and 2 arrows>]>
gap> M:=RightModuleOverPathAlgebra(kQ, [1,2,1], [["a", [[2,0]]], ["b", [[4],[-1]]]]);
<[ 1, 2, 1 ]>
gap> IsIdenticalObj(RadicalOfModule(M), Source(RadicalOfModuleInclusion(M)));
false

You might not worry about this, but it leads to some very strange behavior once you want to work with elements:

gap> R := RadicalOfModule(M);
<[ 0, 1, 1 ]>
gap> inc := RadicalOfModuleInclusion(M);
<<[ 0, 1, 1 ]> ---> <[ 1, 2, 1 ]>>
gap> v := Basis(R)[1];
[ [ 0 ], [ 1 ], [ 0 ] ]
gap> ImageElm(inc, v);
Error, the element entered is not an element in the source of the map, called from
<function "unknown">( <arguments> )
 called from read-eval loop at line 90 of *stdin*
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk>
gap> v in R;
true
gap> v in Source(inc);
false

One easy way to fix this would be to turn RadicalOfModuleInclusion into an attribute. That seems like the most attractive and GAP-like solution to me. But perhaps you don't want it, e.g. for memory conservation reasons.

If you don't want that for some reason, you should then instead probably cache the result of NewFamily in RightModuleOverPathAlgebra in a suitable way.

[fingolfin]

Hmm, I see that e.g. TopOfModule, TopOfModuleProjection are attributes, but RadicalOfModule, SocleOfModuleInclusion are not... I wonder why this discrepancy?

[oysteins]

The big problem here is that if we have the same module represented by two different GAP objects -- that is, two module objects M and N with M=N but not IsIdenticalObj(M,N) -- then an element of M is not treated as equal to the same element in N. Even if we turn RadicalOfModuleInclusion into an attribute (and I don't see any reason not to do that), this general problem still remains.

So we need to either cache families (as suggested) or avoid the family problem by simply having one single family for elements of all modules (and then replace tests involving families by tests for which module the elements belong to). In QPA version 2, I'm currently trying the latter approach. To me, it seems like it's extremely difficult to find a sensible way to use families.