Talk:Concatenated error correction code

	Telecommunication portal This article is within the scope of WikiProject Telecommunications, a collaborative effort to improve the coverage of Telecommunications on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TelecommunicationsWikipedia:WikiProject TelecommunicationsTemplate:WikiProject TelecommunicationsTelecommunications articles
???	This article has not yet received a rating on the project's importance scale.

Concatenated error correction code received a peer review by Wikipedia editors, which is now archived. It may contain ideas you can use to improve this article.

Title

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

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)[reply]

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

ECC_Packet = Outer Code (Inner Code(data))

Decoder

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)[reply]

"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:
||   A   |    ...   |    A    ||             (input: 1 block with K outer symbols, each of size k inner symbols)
             (outer code)                    (encode with rate R)
||   A   |    |   A   |    ...   |   A'  ||  (1 block with N=K/R outer symbols, each of size k inner symbols)
      (optional outer interleaving)          (shuffle outer symbols across neighboring blocks)
||   C   |    |   A'  |    ...   |   B   ||
    (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
||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)[reply]

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#Usage_in_coding. 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)[reply]

About your Third Opinion request:

Disclaimers: Although I am a Third Opinion Wikipedian, this is not a Third Opinion in response to the request made at WP:3O, but is merely some personal observations and/or information about your request and/or your dispute. I have made no previous edits on Concatenated error correction code and have no known association with the editors involved in this discussion. My personal ethical standards for issuing third opinions can be viewed here.

Comments/Information: I'm afraid that your request may languish unanswered at WP:3O for quite a while because of the complexity of the issues involved. (I, personally, am absolutely clueless as to what's involved, much less as to who might be right. I will note, however, that it appears to me that you are arguing over the content of the text rather than the verifiable, reliable sources for that content. If you will both begin by citing sources to support your assertions, it might help focus and/or resolve the debate and avoid impermissible original research. It will, of course, eventually be necessary to cite sources if the text is going to remain in the article, so the effort to find them will not be wasted.) You might get help much more quickly if you would withdraw your Third Opinion request (just go back to the 3O page and delete it from the list of active disputes with a note in the edit summary and remove the {{3O}} template, above, too) and ask for help via a WP:RFC or a posting at WP:TELECOM or some other relevant project. If you would rather have help from 3O, nonetheless, please feel free to leave it listed (but don't ask for help at one of those other places, too, as that can be seen as forum–shopping), but I'm afraid that you may not get it or it may be a long time coming.

Note to other 3O Wikipedians: I have not yet "taken" this request, removed it from the active request list at the WP:3O page, or otherwise "reserved" it, so please go ahead and opine on it if you care to do so. —TRANSPORTERMAN (TALK) 17:59, 11 February 2010 (UTC)[reply]

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)[reply]

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)[reply]

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. — HelloAnnyong ^{(say whaaat?!)} 04:37, 18 February 2010 (UTC)[reply]

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)[reply]