In my opinion, this kata tastes like stale dog water. Why even bother mentioning Huffman Encoding if the kata doesn't require you to actually implement Huffman encoding/decoding? Why all the null vs '' return values? Why only test for the length of the resulting bit string? I didn't even bother with the decoding and still passed.

And yes I did read every single message in the kata. A first for me. The majority of the discussion surrounds just plain old confusion (me included).

Awesome kata! The only thing I think can be improved is adding actual decoding tests in the samples. Right now you only test error handling and empty string in the sample tests, which is not the actual functionality of decode.

lowercase SQL is what we call a "programming war crime".

expected BinaryPolynom{ powers: Set{ 5, 3, 7, 4, 1, 2 } } to deeply equal BinaryPolynom{ powers: Set{ 7 } }

Tests pass.. But something happening when click "Attempt"..

Why and how polinom in your test like "x^7 + x^5 + x^4 + x^3 + x^2 + x^1" should be equal to "x^7"... That's strange..

or when click "Attempt"..
expected BinaryPolynom{ powers: Set{ 7, 4, 6, 3, 5, 2, 1 } } to deeply equal BinaryPolynom{ powers: Set{ 4, 7, 3 } }

There is: x^7 + x^6 + x^5 + x^4 + x^3 + x^2 + x^1 should be equal to x^7 + x^4 + x^3...

I beleave that is bug on your side for JS solution...

In JavaScript, I'm failing two test cases and I'm not sure why:

• Decode test case where alphabet is array of numbers and the encoding is null. The expected return value is the alphabet repeated 4 times. Why is that?

• Decode test case where alphabet is very large array of numbers. First few elements of alphabet are 33,12,5,14... and first few elements of encoding are 0,2,6,8...

  • The expected return value is 33,12,5,14... but how is that correct?

I must be going wrong somehwere, but could someone please help me find where?

That's awesome, thanks!

This appears to only be an issue with the sample tests (the full tests have gen15 = choose (0, 15)). My recently published fork fixes this in the sample tests.

My recently published Haskell fork adds a test case to eliminate these kinds of solutions.

Haskell fork with the following changes:

• Minor tweaks to the test suites
  • Qualified imports from solution module to avoid inadvertent name clashing
  • Replaced choose with chooseInt
  • Improved the generation of random lists of powers
  • Removed unused code from sample tests
• Updated sample tests to use proper ranges, resolving this issue
  • The full tests already used the proper ranges
• Added test in full tests to weed out solutions that use a fixed result for field multiplication, resolving this issue

Test cases are unacceptable for a 3 kyu: this solution should not be able to pass

See this paragraph and this paragraph for explanation.

Code is passing tests but failing the Attempt. I didn't even know that was possible, and can't understand what's happening.