Trying C++, having a problem with random cases.

Failed for diff = 3514, low = 279314, high = 401782
Expected: equal to [  ]
Actual: [ [ 304696, 374643, 378157 ], [ 306740, 552471, 555985 ], [ 312230, 424864, 428378 ], [ 312258, 427352, 430866 ], [ 313234, 514216, 517730 ], [ 313262, 516712, 520226 ], [ 319362, 454680, 458194 ], [ 319684, 483959, 487473 ], [ 319864, 500339, 503853 ], [ 320186, 529664, 533178 ], [ 331446, 351440, 354954 ], [ 332700, 469943, 473457 ], [ 332952, 493811, 497325 ], [ 352814, 598504, 602018 ], [ 392798, 562616, 566130 ], [ 397434, 472768, 476282 ], [ 398438, 586464, 589978 ] ]

You can verify that the actual results are triples satisfying the requirements ;-)
How can the expected result be '[]' ??

Scala assertion messages are unreadable.

Please provide formatted assertions for kata like this, especially white ones.

Since durations are integers, the result is a fraction and could be returned as a Fraction instance instead of percentage float.

Very nice Kata btw.

Hi,

What's the point with the link in the description? (see the comment in my solution, also)
This leads to a very poor kata, imo.

• Those using the info have nothing to do
• Those trying to actually solve the kata will hit a wall, thinking they are facing a 5 kyu while it's at least 3 kyu without the link (it's harder than "Bribe the Guards of the Crown Jewels")

If you decide to keep it, removing that info, tell me so that I remove all the rank suggestions.

Cheers

Sample tests are significantly harder than actual submit tests, running in about 10s for the solution everyone is using whilst submit tests only take 2-3s.

Hi,

Looking at some of the current solutions, I have a feeling that there are no (or not enough) cases like Q..x.y., where the y piece is hidden by the x one. Using various strategies like swapping the board, or the pieces, you should be able to catch most of the implementations that do not consider this (ie: that could catch y instead of x)

Cheers

Now let's create a kata for B... oh, wait

( JS )

Random tests runtimes vary wildly. Try to generate more consistently distributed sizes.

I got different results in my local IDE and on Codewars using the same inputs and code. Did I overlook something here?

It might be a good idea to change the expected output from bad values of n from empty collections to None/null/Option(I think?) in Python/JS/Java for future maintainability reasons. Should be possible to preserve old solutions as well.