is_codeword should be removed or do the same as __contains__ i.e. "c in C"

[Johan Rosenkilde]

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.

[Johan Rosenkilde]

Currently, __contains__ is really badly written (constructs a complete vector space on every call and asks this). The is_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.

[Daniel Augot]

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.

[Johan Rosenkilde]

My suggestion was to have only one implementation, and let both is_codeword and c 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 of c 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 syntax c in C
• We support the syntax c in C and we do not have a method is_codeword()
• We have both and e.g. c in C calling is_codeword.

[David Lucas]

Fixed issue #33 : removed is_codeword method, see issue #47 regarding contains

→ <<cset 55d73f725c23>>