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
When dealing with gap-system/gap/issues/5334 (where test code from the guava package helped to fix a bug in GAP), I noticed a few problems with related code in the file lib/codeops.gi of the guava package.
There are \in methods that take a list of codewords or a code as the first argument (see the ApplicableMethod output shown below). The correct GAP operation for expressing this relation would be IsSubset (with reversed argument ordering). Note that methods installed with requirement IsList for the first argument are applicable also in the situation where the first argument is a codeword, and these methods return false in this case; in these situations, these methods do not cause problems only because other methods have higher ranks. I think it is confusing to "misuse" the operation \in for IsSubset questions.
The \in methods for an object in IsCodeword and a code with certain properties (IsCode, IsLinearCode) have lower rank than more general methods for a vector and a vector space, but the methods for IsCodeword seem to be more efficient. It would make sense to "rank up" these methods. Here is an example in GAP 4.12.2.
gap> V:= WholeSpaceCode( 5, GF(2) );;
gap> v:= GeneratorsOfVectorSpace( V )[1];;
gap> meth:= ApplicableMethod( \in, [ v, V ], 1, "all" );;
#I Searching Method for in with 2 arguments:
#I Total: 117 entries
#I Method 65: ``in: for vector and free left module that is handled by a nice basis'' at /.../lib/basis.gi:1258 , value: 33
#I Skipped:
#I Method 66: ``in: for vector and fin. dim. free left module'' at /.../lib/modfree.gi:83 , value: 32
#I Skipped:
#I Method 69: ``in: method for codeword in cyclic code'' at /.../pkg/guava/lib/codeops.gi:1435 , value: 25
#I Skipped:
#I Method 73: ``in: method for codeword in linear code'' at /.../pkg/guava/lib/codeops.gi:1413 , value: 23
#I Skipped:
#I Method 80: ``in: method for codeword in unrestricted code'' at /.../pkg/guava/lib/codeops.gi:1389 , value: 17
#I Skipped:
#I Method 101: ``in: method for list of codewords in unrestricted code'' at /.../pkg/guava/lib/codeops.gi:1399 , value: 6
#I Skipped:
#I Method 107: ``in: for a domain, and an element'' at /.../lib/domain.gi:280 , value: 5
#I Skipped:
gap> V:= WholeSpaceCode( 5, GF(2) );;
gap> v:= GeneratorsOfVectorSpace( V )[1];;
gap> i:= 4;; for x in [ 1 .. 10000 ] do meth[i]( v, V ); od; time;
33
gap> i:= 1;; for x in [ 1 .. 10000 ] do meth[i]( v, V ); od; time;
115
The text was updated successfully, but these errors were encountered:
When dealing with gap-system/gap/issues/5334 (where test code from the guava package helped to fix a bug in GAP), I noticed a few problems with related code in the file
lib/codeops.gi
of the guava package.\in
methods that take a list of codewords or a code as the first argument (see theApplicableMethod
output shown below). The correct GAP operation for expressing this relation would beIsSubset
(with reversed argument ordering). Note that methods installed with requirementIsList
for the first argument are applicable also in the situation where the first argument is a codeword, and these methods returnfalse
in this case; in these situations, these methods do not cause problems only because other methods have higher ranks. I think it is confusing to "misuse" the operation\in
forIsSubset
questions.\in
methods for an object inIsCodeword
and a code with certain properties (IsCode
,IsLinearCode
) have lower rank than more general methods for a vector and a vector space, but the methods forIsCodeword
seem to be more efficient. It would make sense to "rank up" these methods. Here is an example in GAP 4.12.2.The text was updated successfully, but these errors were encountered: