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)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"2011-10-23T21:46:00.000Z","author":"Nageh","type":"comment","level":1,"id":"c-Nageh-2011-10-23T21:46:00.000Z-Not_happy","replies":[]}}-->
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)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"2011-10-23T22:36:00.000Z","author":"Ylloh","type":"comment","level":2,"id":"c-Ylloh-2011-10-23T22:36:00.000Z-Code_types","replies":[]}}-->
This is a quick sketch for testing a different presentation. Comments welcome. Nageh (talk) 22:21, 25 October 2011 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"2011-10-25T22:21:00.000Z","author":"Nageh","type":"comment","level":1,"id":"c-Nageh-2011-10-25T22:21:00.000Z-Draft1","replies":[]}}-->
Draft2: with headers and collapsible lists
Nice, thanks! I'm not sure I like that the lists for the notation are collapsed, but it's definitely better than just having a link. In your example, things seem a bit squeezed, especially the show/hide buttons: on my computer, they are at a very small distance below 'Linear block code' and below the bracket notation. How about more something like this test box. Ideally, I would like the hierarchy elements and the notation to be centered.
Why exactly do you want the explanation for the notation to be collapsed by default? I know that this adds four lines to the infobox, but there is hardly a lack of space, and I don't think it counts as clutter either. Even though this notation claims to be a standard, the truth is that different authors and different areas use many variations of this notation:
for linear block codes
for non-linear block codes
, etc. for linear and non-linear, block and non-block codes.
I find this situation highly confusing and wikipedia should make it as easy as possible for the reader to understand what is meant. In a paper or in a textbook, we can define the notation in the beginning, but on wikipedia we cannot do that. Therefore, I'd prefer the notation list to be shown by default. ylloh (talk) 16:33, 26 October 2011 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"2011-10-26T16:33:00.000Z","author":"Ylloh","type":"comment","level":1,"id":"c-Ylloh-2011-10-26T16:33:00.000Z-Draft2:_with_headers_and_collapsible_lists","replies":[]}}-->
Collapsible text is neat, but there seems to be no good solution for this template, especially since one cannot change the clickable text that appears to [show] or [hide] the collapsible text. Your draft2 looks pretty good other than that. Below is a new draft; while I think simply noting the Notation would be fine since (n,k) and [n,k,d] are so widespread in coding theory (and anyone can click on Notation to learn about it), I have left in the details as a courtesy. Btw, (n,k) is a notation used for any code, whether linear block, non-linear block, or convolutional code. Have a look! Nageh (talk) 17:34, 30 October 2011 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"2011-10-30T17:34:00.000Z","author":"Nageh","type":"comment","level":1,"id":"c-Nageh-2011-10-30T17:34:00.000Z-Draft3","replies":["c-Ylloh-2011-10-30T18:37:00.000Z-Nageh-2011-10-30T17:34:00.000Z"]}}-->
That looks good, thanks! ylloh (talk) 18:37, 30 October 2011 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"2011-10-30T18:37:00.000Z","author":"Ylloh","type":"comment","level":2,"id":"c-Ylloh-2011-10-30T18:37:00.000Z-Nageh-2011-10-30T17:34:00.000Z","replies":[]}}-->
![{\displaystyle [n,k,n-k+1]_{q}}](https://wikimedia.org/api/rest_v1/media/math/render/svg/40db2e3e8f4c5286a6af80633857ceeb572a14ce)
![{\displaystyle [n,k,d]_{q},[n,k,d],[n,k]_{q},[n,k]}](https://wikimedia.org/api/rest_v1/media/math/render/svg/d68de22d516261b5acc3c09d862122278304a414)
![{\displaystyle \mathbf {[n,k,n-k+1]_{q}} }](https://wikimedia.org/api/rest_v1/media/math/render/svg/6a98f8afc2f17ac1f3ebdd583b428e2ca51020f4)
