The `__eq__` notion for codes

[Johan Rosenkilde]

What is the intended semantics for __eq__ on codes, i.e. the code which is run when evaluating C1 == C2?

I see various possibilities

1. It means exactly same code family and parameters. This is cheap to check, and the current implementation of GRS.__eq__ works something like this. Constructing mathematically the same space but with two different classes would yield inequal codes.
2. It means same linear subspace of some field. This is the implementation in LinearCode and is somewhat more expensive to check (essentially checks that either generator matrix is orthogonal to the other's parity check matrix.)
3. A best-effort of the above. I wanted to suggest something like, if the codes share the same family then check cheap equality, otherwise go to expensive. But then I realised that a GRS code with all-1 col multipliers is the same code as a GRS with all-2 col multipliers. So that check would be semantically somewhat bizarre.

What do you say?

[Daniel Augot]

I am very strongly for solution 2.

First, I suspect there will be many semantic pitfalls when trying to define equality of codes families.

Second, the typical usage would be the following : I have such a code [255,224,32]_256, built in a strange way, or found after some cryptanalysis, I would like to check if it is the standard RS code (say), to check my guess about the nature of the code, or to check if my cryptanalysis has succeeded. In that case, you need equality as " same linear subspace of some field".

Of course, it makesense to ask if a code belongs to a family, and I am perfectly OK with C.is_GRS(), etc, etc, in weak or strong form. But for equality, let us be strict.

Daniel

[David Lucas]

Done.