GRS code constructor can infer arguments

[Johan Rosenkilde]

The arguments F and n can be inferred from the list of eval pts.

[Johan Rosenkilde]

Perhaps the order of arguments should then be eval_pts, dimension, [col mults].

[David Lucas]

Partially resolved in commit b0f16cc : I removed length parameter, which is inferred from the length of the evaluation points list and changed the order of the parameters.

There is a discussion when it comes to F : should we remove this parameter, in this case we force the user to write something like evaluation_points = F.list(), with F the field he wants (else we throw an error) or should we keep it?

[Daniel Augot]

The order of arguments should be eval_pts, col mults, dimension since you place the most constant stuff before. And remember that you have a "filtration", as Alain would say, when eval_pts, col mults are fixed and dimension is growing. This reinforces my idea.

The problem that I see is that [col mults] is an optional arguments.

[Johan Rosenkilde]

I don't know what you mean with "most constant stuff before". But as you say, if we want to keep col mults an optional argument, it has to be after dimension.

[Johan Rosenkilde]

The question David poses about F is one of coercion. Right now, I can write

C = GeneralizedReedSolomonCode(GF(7), [1,2,3,4], 3)

to make a GRS code over GF(7), and because the field is explicitly given, the constructor will coerce the given list of integers to the field.

If we remove F as an argument to the constructor, the user must supply evaluation points which are already in the field. To do the above, one would write e.g.

F = GF(7)
C = GeneralizedReedSolomonCode([ F(i) for i in [1,2,3,4]], 3)

or

C = GeneralizedReedSolomonCode(F.list()[1:5], 3)

[David Lucas]

Resolved issue #19

→ <<cset 367e4e1ee99b>>