okay, the ranking was just my opinion but since it can't be changed, I resolve this suggestion, closing ~~

• Changed to assert.strictEqual
• Why not 6kyu? It was average rank of normal and power users and it was also my opinion. What would you have said?

• assert.strictEqual should be used thooo

• why 6kyu thoooo??!!!!

Somebody listened. Yes, this is a six.

Sorry about the delay. Approving this translation, just wanted to convey the original idea with the encoding:

111001001 --> ~~~--~--~0 --> -1

So the "expected" solution would be more like:

start an accumulator at 0
for every bit, going backwards:
  if the bit is 0:
    negate the accumulator
  else:
    take the bitwise complement of the accumulator
return the accumulator

Since you are sleeping, I will approve the kata now ...

After you approved Javscript Translation, I will approve the kata! :)

This kata is great! I'm going for a JS version :)

I think this question is too easy for 5kyu, I think this question is in 6kyu level

Because (1) I don't want to submit, and (2) it is bad for translations - because in most languages other than Python,

the test framework stops the current block after any failed test

You may recognise this behaviour from JS kata that use current ( not legacy ) Node versions.

I can't really blame you for not knowing, or not considering, this, but it is a consideration for kata creation. You might not even know a translation behaved differently than your Python version, nor might most translators expect this Python-framework-specific behaviour.

I really don't see why not count the submit tests since you are able to print debug statements and see the expected value in them. But so be it -- I have added example tests for inputs up to 4 bits.

Do you mean the example tests or the submit tests?

Because in most languages, the test framework stops the current block after any failed test, so roughly speaking, you get one test per it-block, and you have to Submit for it, and debug print inputs yourself. Generally, a kata should be solvable with only the description. In this case, including the example tests as examples is reasonable. But I would not count the submit tests.

I would not call the 4 description examples ( including "" -> 0 ) and the 5 example tests ( excluding "" ) "lots." "Enough", possibly, "a number of," certainly, but not "lots."

The test cases. If this were an actual encoding you wouldn't have those to break it.

he's given you lots of examples

So where are they?

Something along these lines should be added to the details:
"The bounds of the intersection area are inclusive, meaning that two circles that touch at an integer point without overlapping such as [0,0,1] and [2,0,1] will expect a return value of 1"