Talk:Concatenated error correction code

Title
I'ld prefer to move this over to Concatenated code. Richard Pinch (talk) 19:44, 23 July 2008 (UTC)

You do have a point, but it is still unfit for public consumption. There is no section in the article for people with lesser mathematical backgrounds. Eyreland (talk) 12:07, 6 February 2010 (UTC)

Simplified mathematical overview
The purely mathematical explanations of Concatenated Error Correction Codes are often lost on people with weaker mathematical backgrounds. These error codes are really fairly simple in their operation and effect, so you simply have to ask:

How do Concatenated Error Correction Codes work in real world transmission situations?

In essence you have a datastream that is typically composed of packets containing and obeying the general process or function

Encoder Decoder
 * ECC_Packet = Outer Code (Inner Code(data))
 * data = (Inner Code (Outer Code (ECC_Packet)))

Data chunk boundaries, general properties
 * Outer Code > Inner Code data chunks, generally
 * Outer > Inner, but interpret ">" as meaning "slightly bigger"

The princiapals of the encoding and decoding process work the same weather it be a Compact Disc player or a Deep Space Network telemetry system.

Interleavers (that scramble data by displacement, but do not alter data) and Randomizers (that alter data but do not scramble it) are often coupled with concatenated ECC codes to improve their performance. However, Interleavers and Randomizers are not part of the definition of concatenated ECC codes as they themselves are not really true ECC codes as such. Eyreland (talk) 06:14, 11 February 2010 (UTC)


 * "Thanks" that you repeat what I have explained to you on your talk page. :/ But you did not understand that interleavers do not scramble but shuffle, and randomizers are scramblers.
 * Editing in a very weak non-encyclopedic non-scientific way while ignoring discussion is not a proper way of interacting with people. I have suggested on your talk page how the article could be improved to make it more accessible to less technical people. You have completely ignored that. Just as you keep ignoring WP:MOS, WP:BETTER and the like. Your text always reads more like presentations, uses an informal tone, assumes knowledge of pseudo-code style formatting (so much for accessibility), and fundamentally, ignores scientific facts and references.
 * I am re-posting what I have suggested on Eyreland's user page, for anybody to pick it up:

Thanks for your input. If you want to make the article more accessible to less mathematically inclined people, I think it would tremendously benefit from a simple picture showing how these codes work. Unfortunately, I'm not good/patient enough at making such diagrams, but if you would do it, I would definitely support you.

The diagram (for encoding) would look something like this:

(outer code)                   (encode with rate R)      (optional outer interleaving)          (shuffle outer symbols across neighboring blocks) (map outer symbol to inner block) k symbols  k symbols         k symbols ||c|c|c||  ||a'|a'|a'||  ... ||b|b|b||  (N blocks with N*k inner symbols) (inner code)                   (encode each block with rate r) n symbols     n symbols           n symbols
 * A  |    ...   |    A    ||             (input: 1 block with K outer symbols, each of size k inner symbols)
 * A  |    |   A   |    ...   |   A'  ||  (1 block with N=K/R outer symbols, each of size k inner symbols)
 * C  |    |   A'  |    ...   |   B   ||
 * c|c|c|c'|| ||a'|a'|a'|a''|| ... ||b|b|b|b'|| (output: N blocks with N*(k/r)=N*n inner symbols)


 * If you want to continue editing like that, maybe it is better to draw someone outside in.


 * Thanks for your understanding.
 * Nageh (talk) 11:53, 11 February 2010 (UTC)


 * PS: Simply explaining concatenated codes as code = outer_code(inner_code(data)) is very misleading as it does not explain the properties required by the codes. And the principle between coding on the CD and DSN codes is not so much the same. In fact, your favorite example of the CD is misleading in that it employs concatenated codes in a very loose sense of definition; the essential concept here is interleaving, which - as I already stated to you before as well - should be explained in the proper section of the article at interleaving. AAARRGGHH! I am just seeing that you have edited interleaving and been talking about randomization whereas that article is not about randomization AT ALL!!! And there is not even a confusion between interleaving and randomization until you create that confusion! Ok, it's time to draw somebody in.
 * Nageh (talk) 12:04, 11 February 2010 (UTC)


 * Thank you for your response! I first want to point out that it is always my intention to provide suitable references, and in the specific case in fact most of the information is covered by either external or internal links. This is in strong contrast to the usual text provided by the OP. (You may get a glimpse of through our talk page comments.)


 * Notwithstanding original research by the OP, I was also looking for a 3rd person comment on how to approach the OP on his repeated attempts to provide a "non-technical" description, ignoring my critiques in large. Who knows, I may simply fail to transport my arguments? The issue is, I understand and fully respect the OP's desire to present the information in an accessible way for non-technical people. However, I do not agree with the way the information is presented by the OP, and I instead suggested a diagram, depicting the process of concatenated encoding and decoding. Unfortunately, my comments seem to be in vain.


 * I understand the decision on how to improve accessibility may be dependent on knowledge of the subject, but I'll wait a few more hours before removing the 3O template, just in case there may be some further 3rd person comment.


 * Thanks, Nageh (talk) 21:52, 11 February 2010 (UTC)


 * Please do not take my comments as an attempt to provide the requested 3O. (Though I've have had no dealings with this article or the editors, to my knowledge, I think someone with more time could likely give a more thorough response.)  Anyways, it is my opinion that the proposed simplification is a bit unencyclopedic.  The suggestion to present it as a graphic, likely in the sidebar, I believe is a wise one.  In the end, I don't see the proposed simpolification as lowering the bar all that much, as it's use of function notation targets an audience that is pretty likely to understand the un"simplified" material.  But, I guess a graphic with some blocks and envelopes or some such could be pretty layman-accessible.  I'm not really sure why laymen would be interested in the topic, but I guess that's not quite relevant. Lastly, more citations would be helpful. BigK HeX (talk) 19:19, 16 February 2010 (UTC)

Third opinion
Hey all. I'm gonna take a shot at this, but I have to admit that this stuff is over my head. I can tell you, though, that I agree with this reversion. BigK Hex was right that it's unencyclopedic; the tone of text like "These error codes are really fairly simple in their operation and effect, so you simply have to ask: " is inappropriate. Among other things, Wikipedia is not a how-to.

Having said that, I have a larger issue with this article, in that it's written for a very specific group of people - that is, people who understand what these codes are. Honestly I would prefer if this article was a bit more approachable for someone without prior knowledge of coding theory. That's not to say that we should dumb down the article or write text in the second person and so on, but it could be a bit less jargon-y. —  Hello Annyong  (say whaaat?!) 04:37, 18 February 2010 (UTC)

Thank you, all the reviewers, for your comments! I think they help clarifying the issue over how to present the article content. As I said before, I respect the desire to make the article accessible to an audience as broad as possible, however, this should not come at the price of over-simplifying or dumbing down the subject. Coding theory is an expert subject, and any introductory text may be more appropriately addressed by the more general articles, such as coding theory, forward error correction, and error detection and correction. Concatenated codes is not something a layman would be overly concerned with, in general. Having said that, I will try to enhance the lead section with some more introductory text on the topic, but the rest of the article will roughly stay as is in terms of accessibility (though I have already suggested improving the article with a diagram). So I think, in the end, most of us largely agree on this conclusion. Thanks again, Nageh (talk) 15:49, 18 February 2010 (UTC)