Explain why this "Reed-Solomon' differs so much from storage ones#17
Explain why this "Reed-Solomon' differs so much from storage ones#17burdges wants to merge 1 commit intoAndersTrier:masterfrom
Conversation
|
Hi Jeff Thanks for the PR! You're right, that should be documented somewhere. I think the explanation is a bit too verbose though. How about just stating something like:
That's also more aligned with what Klaus documents in his implementation:
|
|
As you like of course.. I sent some contact details by email, so maybe worth a brief off-line chat about langauge. I typically prefer brevity like Klaus comment, but here I'm really addressing the concern raised in your PR to reed-solomon-16, by distancing this crate from matrix multiplication and error location, correction, and checking. |
This PR malaire/reed-solomon-16#1? What concerns did I raise in that PR that you're addressing? Note on hash now merged: #18 |
|
I think the long version would go well in the wiki, if that's a feature you want to enable for this repo. |
|
I think this should go in the rust docs in |
Although much faster for high shard counts, this crate provides rather different functionality from classical Reed-Solomon built upon syndrome decoding, etc. It's likely worth some explination.