- edited description
Notation and aesthetics
Issue #95
new
We should use a constant and clear notation. Please discuss the following:
F
the alphabetm
is a messagec
is a codewordr
is a "received word", in case of a transmission (a channel)y
is a word is the ambient space, for an abstract decoding probleme
is the errorC
is for a codeG
is for a generating matrixH
for a parity check matrix.S
is for a syndromEnc
is for an encoder, or may beE
Dec
is for a decoder or may beD
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 codesZ
is the variable for locator polynomials in the "transform" domain.
Comments (9)
-
reporter -
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter Please comment on these notations. Since David is starting to do more and more implementation, it would be nice to have a uniform notation.
-
- GRS evaluation points should be
eval_pts
,eval_points
oralphas
. 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 justx
.
- GRS evaluation points should be
-
I agree with the rest, btw.
- Log in to comment