You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Hmm, I see that e.g. TopOfModule, TopOfModuleProjection are attributes, but RadicalOfModule, SocleOfModuleInclusion are not... I wonder why this discrepancy?
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.
You might not worry about this, but it leads to some very strange behavior once you want to work with elements:
One easy way to fix this would be to turn
RadicalOfModuleInclusion
into an attribute. That seems like the most attractive andGAP-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
inRightModuleOverPathAlgebra
in a suitable way.The text was updated successfully, but these errors were encountered: