Either tighten the performance requirements to require actual optimisation (I have no idea if any exists) or remove the "performance" tests as there is no way to fail them. All they do is annoy the user.

Implementing the algorithm exactly as laid out in the description clears the tests (and is intended to) so why make it take several seconds when milliseconds is enough to verify correctness.

The challenge mixes up strings and bytes in a confusing way. The FVN is defined for bytes, but input for the function is string, and it's not explained what is the expected way of getting bytes from strings. In C# translation it is even more confusing, because the reference solution does not operate on bytes at all.

The functions should ideally accept arrays of bytes as input. If they accept strings, it should be explained what is the expected way of getting bytes from a string, and tests should test for inputs which translate from strings to bytes in a non-trivial way.

Modifying the input breaks the random tests.

there is no "example of the working code" in the description when selecting JavaScript. When selecting C++, both the algorithm and the "working code" are written in Python

hi, I would reccomand having a small edge case section in the code for (0,0), (1,1), (0,1), (-1, 0), (-1, 1) etc preferably in the sample test also
also, maybe adding some random testing would be a good idea, however make sure you genrate random ints and cast them to longs, as dealing with the edges of representable numbers was not defined.
best of luck :)

Current reference solution is wrong, for example:

books = {
    "0": "zero",
    "1": "one",
    "2": "two",
    "3": "three",
    "4": "four",
    "5": "five",
}
word_limit = 3

The length of the answer list should be C(6, 3) = 20 instead of 9.

Log
[((4, 4999999), [7, 6]), ((3, 5000000), [6, 7])]
Ten Million Numbers With Middle Pair: Should terminate with a valid pair output: [7, 6] should equal [6, 7]

&

Log
[((6, 9999998), [-3, 8]), ((5, 9999999), [8, -3])]
Ten Million Numbers With Pair At End: Should terminate with a valid pair output: [-3, 8] should equal [8, -3]

The above log shows a list of tuples, in which the first tuple is the iterator, the second the index of the matching pair.
As you can see the output insists the matching pair where the second values index is larger is the answer.

What's the deal? All the other tests pass. It's just these tests.

Scala translation

Since there is a performance tag, the input size should be provided.

NO random tests in

• Elixir
• JS
• Ruby
• Rust
• TS

Typescript translation https://www.codewars.com/kumite/63088f73f22754000fa5a983?sel=63088f73f22754000fa5a983