Template talk:Infobox code

Not happy

I'm not too happy with this infobox. For one, it contains excessive redundant information. IMO it suffices to include Named after, Type, and Notation - for block codes, at least. A single click on notation reveals any further information required to interpret its parameters. Second, the box does not consider convolutional codes, which are defined by constraint length rather than block length and message length, or rateless codes, which do not have a predetermined block length or code rate at all. Regarding code type, which one do we want to give? Do we only want to distinguish between linear/nonlinear block codes, convolutional codes, and probably rateless codes? For example, the class hierarchy of RS codes may be given as RS codes ⊂ BCH codes ⊂ cyclic codes ⊂ polynomial codes ⊂ linear block codes. Or do want to indicate the next class of codes in such hierarchy? Do we want to point out particular properties, like whether the code is perfect, whether it is optimal (MDS code), or that particularly efficient algorithms exist (like for Fountain codes, which are linearly en-/decodable)? Other than that, I think the principal idea of an infobox for codes has some appeal. Nageh (talk) 21:46, 23 October 2011 (UTC)

Thank you for your message! I am sorry that you are not happy with the infobox. You bring up two issues that I am also not entirely happy with, but I think it's a good start.

Redundancies

I agree that there is some redundancy, but I wouldn't call it excessive. After all, I wanted to present the data in such a way that the interested wikipedia reader can decode and understand it easily. Redundancy helps here a lot. I am not a coding theorist myself, for which reason I know that the popular notation was very confusing to me at first. The redundancy of the infoboxes is for non-experts who do not want to decipher this notation to find out what's going on. Going one click and doing pattern matching with the four symbols is simply not a thing that I want to do. If you want to reduce redundancy with the notation, then I am in favor of deleting the notation field. The only other type of redundancy is that the rate is determined by the message length and the block length. In numerical cases like the Hamming(7,4), I think it's nice to see the number. In cases like the Reed-Solomon code were the parameters are just k and n, it's indeed a bit silly to write k/n, but if someone's really unhappy with this, they can edit Reed-Solomon code and delete the rate entry.

Code types

Indeed I designed the box with block codes in mind. Maybe this infobox should really be an infobox for block codes. I've added the box only to block codes so far, and I do not plan to add it to non-block codes. As types I've always chosen linear block code, but I am not sure this is the best thing to do. Having a mechanism to display the hierarchy to which the codes belong would be nice. It would also be nice to have information about further combinatorial and algorithmic properties of the codes.

If you have an idea about how to accommodate other code types, please go ahead and add the entries to the infobox template. Remember that this is fine since the entries of the template are optional.

ylloh (talk) 22:36, 23 October 2011 (UTC)

Test

Reed–Solomon codes
Named after	Irving S. Reed and Gustave Solomon
Type	Linear block code
Hierarchy Reed–Solomon code BCH code Cyclic code Polynomial code Linear block code
Notation	$[n,k,n-k+1]_{q}$
Block length $n=q-1$ Message length $k$ Distance $n-k+1$ Alphabet size $q=p^{m}\ (p{\text{ prime}})$
Remarks	MDS code

This is a quick sketch for testing a different presentation. Comments welcome. Nageh (talk) 22:21, 25 October 2011 (UTC)