Notation and aesthetics

[Daniel Augot]

We should use a constant and clear notation. Please discuss the following:

• F the alphabet
• m is a message
• c is a codeword
• r is a "received word", in case of a transmission (a channel)
• y is a word is the ambient space, for an abstract decoding problem
• e is the error
• C is for a code
• G is for a generating matrix
• H for a parity check matrix.
• S is for a syndrom
• Enc is for an encoder, or may be E
• Dec is for a decoder or may be D
• support is for the evaluation points
• any idea for column multipliers ? lambda is a Sage keyword
• any idea for a channel ? channel is nice, I think
• X is the variable for cyclic codes, for polynomials evaluated in GRS codes
• Z is the variable for locator polynomials in the "transform" domain.

[Daniel Augot]

Please comment on these notations. Since David is starting to do more and more implementation, it would be nice to have a uniform notation.

[Johan Rosenkilde]

• GRS evaluation points should be eval_pts, eval_points or alphas. The word "support" mean something else in the rest of the world of math, so I think we should not use that.
• In Codinglib, I use ws for column multipliers (w in plural). col_mults is of course a possibility.
• Chan is good for channels, I think.
• Polynomial ring variables should be lower case, I think. So x for cyclic codes.
• I don't think that we should create different polynomial rings for different purposes, over the same ring. So -1 for z as variable in "transform" domain (a very engineering-like terminology which I also think we should avoid). In Codinglib, it's always just x.

[Johan Rosenkilde]

I agree with the rest, btw.