Nice comment

hard to tell with codewars diffs being what they are, but I think you messed up the description

loved this one, ty!

Not at all! It's a really bad practice iterate the same array twice. If a person who's starting with Javascript see this, it won't understand at all.

I think he noticed that but he just sacrificed performance for compactness

I changed the messages a bit, could you please check if they are clearer now?

Would you also be so kind to share what other kata you found buggy, so I could check what was your mistake and help you solve them?

I have literally no idea what you are trying to complain on. The kata looks good(ish).

When you see following output:

Testing for hanoi(10)
    19 should equal 1023

It means that:

• In this test, disks was 10.
• Your solution returned answer 19.
• Correct answer is 1023.

I tried your solution and it's simply incorrect, and messages tell you this. Maybe not in the clearest way, and I will try to improve it, but still, wrong solutio is wrong.

testcases changing magically!

in one case it says 3 should result to 7, another try 5 should result in 7!

LOL sorry, but this is really not the first buggy kata I found!
I am just happy to use a unique username and password for this forum ;)

Approved

Thanks, I'll solve it and have a look!

here's a similar Haxe translation, with Int64: https://www.codewars.com/kumite/5f0d74cc28ca50001b1c9ec0?sel=5f0d74cc28ca50001b1c9ec0

Alright, I tried to use Int32 as input args and Int64 as output in the Kata, however, I ran into the same issue I had when translating a different Kata in Haxe. For now, I have saved the fork just in case, but it looks like there's a Null Access somehow. Note: it's still an "update" in progress in the meantime.

Uncaught exception Null Access
/workspace/.haxelib/utest/1,10,1/src/utest/ui/text/PlainTextReport.hx:63: characters 12-27 : Called from here
tests/CodewarsReport.hx:43: characters 58-70 : Called from here
tests/CodewarsReport.hx:86: characters 11-23 : Called from here
/workspace/.haxelib/utest/1,10,1/src/utest/Dispatcher.hx:34: characters 9-13 : Called from here
/workspace/.haxelib/utest/1,10,1/src/utest/ui/common/ResultAggregator.hx:99: characters 5-30 : Called from here
/workspace/.haxelib/utest/1,10,1/src/utest/Dispatcher.hx:34: characters 9-13 : Called from here
/workspace/.haxelib/utest/1,10,1/src/utest/Runner.hx:313: characters 5-30 : Called from here
/workspace/.haxelib/utest/1,10,1/src/utest/Runner.hx:385: characters 5-21 : Called from here
/workspace/.haxelib/utest/1,10,1/src/utest/Runner.hx:358: characters 5-15 : Called from here
/workspace/.haxelib/utest/1,10,1/src/utest/Runner.hx:274: characters 5-22 : Called from here
tests/RunTests.hx:12: characters 5-17 : Called from here

EDIT: Nevermind, was wrong.

• Is Int 64 bit, or 32 bit? Would it be possible to make it 64 bit?
• Randomly spraying over such a small domain is not really the best method of generating inputs. Would it be possible to have inputs generated as a shuffled array of all values from 1 to max?
• Input equal to max bit size of expected result is an edge case for this task because it can trigger an overflow. Would it be possible to ensure that there is a guaranteed test for disks equal to 31, or 32, or 63, or 64 (depending on what Int is in Haxe), either as a fixed test, or as one of inputs of random tests which would be guaranteed to appear?

You can see C or C++ tests for some ideas.