I hope, new tests with 'IllegalArgumentException' as error signal will work.

Random tests ready.
While working, accidentally dropped Blind4Basics' solution into the solutions section (however, with comment), sorry.
I've used it as reference one to adjust tests.

Hello, Toderesa97, need a couple of hours more - do correction in random tests; will update them in a minutes and then write random wrong formatting test. Thank you!

Approved. Just make sure to modify the description accordingly

Will rework random tests a little, and write one for non-correct expression format.

I've just published updated version with 'IllegalArgumentException' as error signal, and portions of random tests.
One's else solution is strong enough to pass them.

I'm trying to resolve kata issues and this can break previous solutions, sorry for that.
Would it be convenient to edit in place?

Ready now.

1. printf now uses "%"PRIu64 macro from <inttypes.h> to print uint64_t
2. "... all of the smallest 5,000 (Clojure: 2000, NASM: 13282) Hamming numbers ..."
3. Ok, removed

Function signature changed to "uint64_t hamming(int n)".

Published, but not ready yet - will do some testing, about 1 hour else.

Thank you; will correct this issues.

n: 3963, expected: -489623040, but was: ...

%d isn't a correct format specifier for int64_t.

Your code should be able to compute all of the smallest 5,000 (Clojure: 2000) Hamming numbers without timing out.

If the range is different, the description should be updated.

// Smallest hamming numbers see at ...

If the link wasn't included in the description by the author, it probably shouldn't be in a language-specific block either.

NASM translation

Thank you for reading and answering, it's very helpful for me.

My questions were mostly about real process, when we have transmitter and receiver:
i) how can transmitter use coding table (e.g. a:0, b:10, c:11) provided by receiver?
ii) when transmitter creates one, how can receiver receive that table or re-calculate it self?

Here, serialization is projection Map<Character,String> -> List (e.g. ["a 0", "b 10", "c 11"]).

Encode message: aaaabcc -> 0000101111;
or aaaabcc, ["a 0", "b 10", "c 11"] -> 0000101111
Decode: the inversion of above.

Ok, the description is consistent, and so;
should test system be able to decode result of Huffman.encode("aaaabcc")?
Guess this is not part of kata problem.
I agree with this too.

freq(b+c)=3 is shortly the same as description (Tree construction, "... This node gets reinserted and has the sum of the frequencies of both trees as new frequency.").

a) serialize coding table calculated,

Meaning what exactly?

b) encode message;

?

So, there are 4 methods in kata api, and 2-a), 3) are not the same as haskell variant.

Why? Can you provide some examples because I cannot follow your description.

I think, it's more clear how to work with code table, then just 'decode a bit sequence using the given frequencies' (haskell kata description).

I think it is part of the fun to figure out how to best do something. Also that's the comment on the decode function and not the description. The description goes into detail and explains the basic concepts.

When "usually we choose 0 for the left branch and 1 for the right branch", shouldn't be b:11, c:01 if a:0?

No, it should not. The description is consistent, please read again.

a=0 and freq(a)=4 > freq(b+c)=3; so last code letter for c should be the same as first for a, because of freq(c)=2 > freq(b)=1 (in accordance with select branch rule.

freq(b+c)=3 meaning what? Define first.