is_codeword should be removed or do the same as __contains__ i.e. "c in C"
In the existing design one can say c in C
to ask whether c
is a codeword in the code C
. This seems more elegant than having an is_codeword
.
I'm not strongly against having both, though, but they should of course share implementation.
Comments (4)
-
reporter -
If you have both, it should be clear that is_codeword is always faster. It is like "is_zero" and "eq zero_matrix(10000,10000)" (in some langage I just invented) applied to huge matrices. Then second may build a large matrix and check equality, while the first one would not need to.
If you are afraid of users stupidly using "c in C", then redefine at the highest level in the framework contains in terms of is_codeword.
-
reporter My suggestion was to have only one implementation, and let both
is_codeword
andc in C
run the same code. Clearly they have the same semantics so there is no doubt it should be the same code. I was unclear because I started also mentioning that the implementation ofc in C
is currently not efficient. We should think of the most efficient implementation for this semantics and do that. I'm not sure it's the parity matrix thing.What is really the question of this issue, however, is which of the following three should be the case
- We have a method
is_codeword()
and do not support the syntaxc in C
- We support the syntax
c in C
and we do not have a methodis_codeword()
- We have both and e.g.
c in C
callingis_codeword
.
- We have a method
-
repo owner - changed status to resolved
Fixed issue
#33: removed is_codeword method, see issue#47regarding contains→ <<cset 55d73f725c23>>
- Log in to comment
Currently,
__contains__
is really badly written (constructs a complete vector space on every call and asks this). Theis_codeword
that David stole from Codinglib computes a syndrome using a parity check matrix and checks whether this is zero. I suppose that the vector space implementation does a similar thing. We should think about what is most elegant while staying general.