Well, thank you for your feedback. It fills me with joy that even years after I created them, people still spend time completing them. Also, thanks to all the translators.

If you do not want cheaters, you have to make it more challenging. ;)

Which language is it? It seems likely that your solution is incorrect. I.e. the trees you construct may not be optimal for a specific corner case. See one of my answers below on this specific test.

If you think there is an issue, I would have to ask you to reopen it.

It should not pass. If it passes then the number in the tests is probably chosen too small.

The example explains the available API of Thunk, the return types (minus casts for unboxing), and how to delay and force computations. If you have any more concrete points I would ask you to open new issues with more details.

If the frequencies resemble ascending powers of two, one would expect the encoding to have an ideal representation (i.e. code length matches the frequency).

      ... 8
     /   \
    /     \
  ... 4   c:4
 /   \
a:2 b:2

If you build a tree, then all of the previously added elements frequency sum is the same as the frequency of the next element. Thus the new root node should have the previous tree and the new leaf as children. The length of the encoding then is the same as the depth of the leaves, and this way it is validated.

If this test fails, then something with your algorithm is broken.

Done, thanks!

It is meant to be a puzzle. If I provide the algorithm, then what is the challenge? You have to figure out how to reconstruct the shifts by yourselfs. Obviously, you can also google it.

This solution was meant to expose the lazy testing of this kata. My actual solution is here: https://www.codewars.com/kata/reviews/54e4b5cfd5e01959820000b5/groups/55e36e2cda32c7934600006e

Ha, I can't even remember.

Thank you for the feedback:

• Can you give an example?
• It should be visible by the test names. It should refer to "sequences" and "prime sequence".

Sorry, I hope it's fixed now because I could never reproduce the original issue.

Examples and informal text can be specifications. Tests should filter out wrong behavior. I agree that Thunk should be tested.

but what if his implmeentation of repeatS is wrong?

headS and tailS are given as is the type. If it is wrong then the corresponding test will fail including others.

you give examples of use of the Thunk class, but you don't give the basic use of Thunk within a Stream

See it as a puzzle.

next part in the sample tests, I need to have implemented takeS while the other static methods aren't tested yet.

Well, if you can't gettakeS right then this Kata probably is not for you. If I have to spoon-feed everything, then the whole thing loses its charm.

Thanks, sorry for the delay.

Can you give more details? What would you like to see improved? Which behavior is unclear in particular? I was hoping the example makes the behavior clear for Thunk.