On Tue, 24 May 2016 12:14:12 -0500, Tim Wescott
>On Mon, 23 May 2016 12:46:22 -0500, Tim Wescott wrote:
>> On Sat, 21 May 2016 14:55:38 -0700, kortas.manel wrote:
>>> Le mercredi 31 août 2005 20:35:16 UTC+1, Mike McLernon a écrit :
>>>> I'm building an erasures decoder for Reed Solomon codes, and I'm
>>>> having trouble when the number of erasures (without errors) exceeds
>>>> (n-k)/2, the error-correcting capability of the code. When my code
>>>> has no errors, and only erasures, I would expect the error locator
>>>> polynomial to be uniquely 1.
>>>> When I have up to (n-k)/2 erasures, that's exactly what happens.
>>>> However, when the number of erasures exceeds (n-k)/2, my error locator
>>>> polynomial exhibits unusual behavior. I run into the following
>>>> circumstances in these cases:
>>>> 1) the polynomial has no roots in the field of the code, or 2)
>>>> the polynomial has repeated roots, or 3) the polynomial's roots are
>>>> a subset of the erasure locations, or 4) the polynomial's roots are
>>>> different from the erasure locations.
>>>> Scenarios 1-3 seem reasonable, in that I can discard the information
>>>> in the error locator polynomial. I already have that information from
>>>> the erasure locator polynomial. However, scenario 4 is troublesome,
>>>> and I'm not quite sure how to handle that one.
>>>> Any help would be appreciated.
>>>> Mike McLernon
>>> can any one provide me the source code of reed solomon in matlab with
>>> BM or euclidien or PGZ method please? thx in advance
>> Not for free, generally, and not if you're a student, ever. We and you
>> both benefit from you doing your own homework. If you can't do your own
>> homework -- switch majors.
>Boy, that was harsh. And I forgot the rider: we're pretty much
>universally opposed to _doing_ your homework for you, but there's quite a
>bit of us (myself included) who are delighted to _help_ you to understand
>your homework so that you might do it yourself.
>We _won't_ help to raise up a generation of ignorant engineers who spend
>a minimal amount of time screwing things up before becoming managers and
>_really_ screwing things up. But we're happy to help raise up the next
>generation of _competent_ engineers.
That's about as well as I've seen that put for a while.