There is no \0 at the end of the input. I know this isn't necessary, as the input is always 3 chars long, but it would be good to conform to most other katas.

Also, this shouldn't cause any katas to be invalidated, so I see no reason not to include it.

I wonder if this BF interpreter is optimized to run operations such as [- > + <] or [-] faster.

My solution relied a lot on these and testing it on my own interpreter, it would definitelly time out a string of length 1000.

Maybe using a Python 3.7 IDE on my phone isn't the best for benchmarking. But running the code on codewars feels way faster than it should.

Far from a problem BTW, in fact, quite a good thing. It's just a question really.

Hi Grzegorz,

JS translations of the kata from your [BF] series need update to Node 14, because they are still stuck at Node 8.
At the same time, they already have an BF translation, which is enough - JS version is, actually, not needed anymore and could be removed.

Would you be so kind to take care of the JS translations of your BF kata, either by removing JS version from them completely (preferrable), or by updating them to Node 14? Thanks!

This kata is a subject to deduplication process here: https://github.com/codewars/content-issues/issues/115.
Please join the discussion to help us identify duplicate kata and retire them.

C translation

Duplicate of "add big numbers" katas.

You should clearly specify in the description that input numbers should be converted to strings and then summed as decimal numbers. The most precise answer for 0.1 + 0.2 is 0.30000000000000004 if inputs are floating-point numbers.

duplicate to many

@gkucmierz: please unpublish your kata (see messages below).

Duplicate of https://www.codewars.com/kata/find-primes-in-range-complexity-matters

the tested number has to be displayed in the assertion message when an error occurs.

Duplicate to many katas

The kata author is not even trying.