CODINGCONTRACT: HammingCode: Clarify difference between Wikipedia implementaion and in-game implementaion

[bupjae]

The Coding Contract description for HammingCode mentions wikipedia article as refernece.
However, in-game uses slighty different coding scheme than wikipedia article.
Namely, we add one extra parity bit at the very beginning of binary string, compared to wikipedia article.

It seems that in-game scheme is also used widely as it has its own advantage (i.e. SECDED).
However, for players, they have hard time when their implementaion which follows wikipedia article doesn't work well.

I think clarifying difference on scheme between in-game and wikipedia article will be helpful.

[gmcew]

This contract type/pair feels particularly problematic for wording clarity and brevity - I think it's worthy of note that these are the only contracts we link out to external resources on - so thank you for bringing this up.
There's been a few updates to phrasing on this recently to improve understanding - if you have some wording in mind feel free to make a PR or summarise it here!

Namely, we add one extra parity bit at the very beginning of binary string, compared to wikipedia article.

The wiki article makes references to 'extended Hamming codes' in a few places to explain the purpose of the additional parity bit, but I agree the example in [8,4] Hamming code with an additional parity bit is misleading in that the additional bit is at the "back end" (P2^N rather than P0).
The current binary-> dec contract wording attempts to clarify this in the introduction by refering to "position 0" as the bonus parity bit, but I'd appreciate your thoughts on how to tweak it. It's also likely similar improvements can be applied to the dec->binary wording. Intro for bin-> dec context below:
You are given the following encoded binary string: '${n}
Decode it as an 'extended Hamming code' and convert it to a decimal value.
The binary string may include leading zeroes.
A parity bit is inserted at position 0 and at every position N where N is a power of 2.
Parity bits are used to make the total number of '1' bits in a given set of data even.
The parity bit at position 0 considers all bits including parity bits.
Each parity bit at position 2^N alternately considers 2^N bits then ignores 2^N bits, starting at position 2^N.

Would The additional parity bit at position 0 considers all bits including parity bits. be a good start?

[d0sboots]

This contract type/pair feels particularly problematic for wording clarity and brevity

I agree with this more than anything else. Overall I like this coding contract, but knowing what I know now, if I were the one deciding if it should be added I'm not sure I'd say yes. XD
We've had so many attempts to make it more clear, and obviously we're not done yet.

[bupjae]

Not too bad. However, it may not sufficient to mitigate the confusion from wikipedia.

I would like to add Note: this problem uses slightly different scheme from Wikipedia article, regarding additional parity bit or the like on the end of description.

Another solution could be removing Wikipedia article from description, as other reference (3Blue1Brown videos) uses exactly same scheme. However, I couldn't recommended this.

[gmcew]

Apologies for taking a while on this. There's a linked PR now, I'd appreciate your thoughts @bupjae (and anyone else!)