Dynamically select the "family" of a code

[David Lucas]

A few weeks ago, we discussed the following point with Daniel and Johan :

Consider a code, which was created as an a-type code. While performing some experimentations on it, you discover that this code is b-typed too. For instance, you create a GRS code, and you discover that the chosen evaluation points made this particular code also cyclic. Maybe you now want Sage to see your GRS code as a cyclic one, so you can access the Cyclic code specific functions, encoders, decoders etc.

How can we do such a thing?

[Daniel Augot]

Well, I am not an expert in typing in python. But for a statically typed langage, you would provide "cast" or "coercion" function, to copy something of type a to something of type b, for instance an element x of a field K into a diagonal matrix with x.

Since python is duck typing, would not it possible to "attach" or "hook" functions to the code of type a, so that is looks like a code of type b ?

[Johan Rosenkilde]

That's exactly the issue. Let's say your code is a of type A. There are basically those two solutions:

1. Provide a coercion function to any element of class A, which will return an element b of class B representing the same code (when possible, otherwise throw an exception).
2. Dynamically patch the a such that it now dynamically inherits from B (or at least provides all the same functionality).

In most OO-languages, 2) is not an option. But Python, JavaScript and similar crazy languages allow this. The question is whether one wishes to (ab)use that power.

Pros/Cons for 1:

1. It is rather simple and clean: it doesn't need strange mingling with Python internals, and it is easier to read and understand.
2. It allows a and b to behave quite differently on generator_matrix, encode, etc. without having to additionally specify when you want the representation as an A code or a B code.
3. a and b will be different objects even though they are the same code. "Discoveries" about b (e.g. its precise minimum distance) will be difficult to transfer programmatically to a. The primary purpose of wanting this would be to allow methods on a to then in turn improve other knowledge of the code. I have no concrete examples of this at hand, however.

Pros/Cons for 2:

1. a and b will be the same object, just as they are really the same code.
2. It is type-wise dirty and bizarre, and it is not easy to read for a new-comer to the code (i.e. needs heavy documentation).
3. Changes to class B potentially requires updates to all classes such as A which can coerce to B. For instance if one introduces a local, private field to B to cache or remember some pre-computed stuff. Read: a simple change to B which works within B itself might break all coercion functions to B.

I vote for solution 1.

[David Lucas]

Implemented for cyclic codes.