Talk:Erasure code

Suggested merger

The Optimal_erasure_codes_with_arbitrary_parameters contains a great example + easier to follow introduction that I think really belong in the primary article. Derek farn 19:18, 27 May 2007 (UTC)

Appears your suggestion was accepted? —Preceding unsigned comment added by 75.169.187.131 (talk) 12:20, 1 June 2009 (UTC)

FFT style oversampling

It looks possible to do oversampling during the encoding stage with an FFT style algorithm, which will be faster than the algorithm currently described. Is this possible ? It will only have a benefit when sending large amounts of information over a reasonably noisy channel and then the benefit would be relatively small (compared to, say, compressing the data better). Is it practical ? -- Nic Roets (talk) 13:11, 10 June 2009 (UTC)

if I'm right, this kind of approach have been studied for Reed Solomon codes, but I don't have any reference ... Cunchem (talk) 17:40, 10 June 2009 (UTC)

Tie-in to Shamir's Secret Sharing?

It seems to me that Shamir's Secret Sharing is an example of an erasure code, with additional security properties not necessarily shared by other erasure codes. It might be useful to have cross-references back and forth, and ideally also a discussion of how Shamir's algorithm is different (or has additional properties) vs. other erasure codes. Paul Koning (talk) 18:24, 31 August 2011 (UTC)

Good point, though I'd say it is actually an application of an optimal erasure code. Cross references could be useful, I agree. If you would like to tackle it feel free to go ahead. Nageh (talk) 11:59, 1 September 2011 (UTC)

Shamir's code has the property that you have zero information until you have the required number of pieces (a "threshold code"). Is that true for other erasure codes? Some of the applicable math is well over my head, but I get the impression that other erasure codes are not necessarily threshold codes. Paul Koning (talk) 21:04, 16 September 2011 (UTC)

It is true for optimal erasure codes. You can easily prove that using information-theoretic arguments and/or via contradiction. Nageh (talk) 23:58, 16 September 2011 (UTC)

Nageh, I agree that Shamir's secret-sharing is a kind of erasure code, and these 2 articles should reference each other.

But no, that property is not true for other erasure codes.

Most other erasure codes usually give a receiver some information after receiving only one piece of the transmitted message.

Most other erasure codes (and more generally most error detection and correction codes) are a "systematic code" -- i.e., the transmitted message is typically a complete copy of the original data ("data bits"), followed by some "check bits". With any systematic code, if someone gets even 1 bit of the transmitted message (in the "data bits" section), that directly tells them 1 bit of information about the original data. Shamir's code is *not* a systematic code.

In other words, the threshold of the cliff effect is a different kind of threshold (the minimum to recover the *entire* message perfectly) than the threshold of the Shamir secret-sharing code (the minimum below which the receiver gets *zero* information).

How can we fix one or both of these articles to prevent this kind of misunderstanding? --DavidCary (talk) 21:39, 18 February 2023 (UTC)

spelling alphabet

I'm kind of not seeing what spelling alphabet has to do with here, propose its removal, will do so in a week if no feedback here. Rogerdpack (talk) 18:34, 19 November 2015 (UTC)

Relation to Deletion codes

Deletion code currently links here, but I don't think those are the same thing. If you read On Deletion Codes or these lecture notes, deletion codes solve the problem where the receiver doesn't know which symbols were lost during the transmission. E.g. in the example about Err-Mail, Bob would receive (777, 851), but wouldn't know which of (C, D), (C, E) or (D, E) they corresponded to. Ideally, a separate article should be made, but we should at least add a sentence to distinguish the terms in this article. Thomasda (talk) 13:23, 2 June 2020 (UTC)