This is missing a whole lot of cases, no?

Here's a few:

"The Giggling Sisters (10000) dir. Bob Bob, Bob Bobbet" <- The _ Sisters in wrong location, and surname Bob, followed by a Bob as first name
"The Giggling Sisters (10000) dir. Your Mom, Second Mom, and Also Dad" <- False? Because not exactly two
"The Giggling Sisters (10000) dir. The Sisters, Those Brothers" <- starts with The, contains brothers/sisters, ends with Brothers
"The Giggling Sisters (10000) dir. A B, C B (20000) dir. The Sisters, Those Brothers" <- Weird title. permissible?
"The Giggling Sisters (10000) dir. The A Sisters, The A Sisters" <- A Sisters mentioned twice, thus should be False

Description mentions "Several guys" but I don't see the word "and" used anywhere in the test code at a glance. That'll cause people to write code for this - except it.. isn't part of the task?

The tests are very small, your code probably wasn't too slow but rather got stuck in an infinite loop.

You will be provided with two object arrays.

wording is too C#-specific (and is probably not an appropriate type for C#)

additionally, description does not state that the given positions are for a knight and a bishop, the description thus does not state what the problem to solve is. those pieces could be pawns for all I know from reading the description

it is also a very strange and indirect way of stating that only two pieces exist on the board

It could instead read something along the lines of:

You will be provided with the positions of a knight and a bishop on a board that is otherwise empty (e.g. [4, "C"] and [6, "D"]).

That's an interesting situation you found. It's a strange thing to be testing without any corresponding specification - it has purpose but I think the test output should be phrased differently because that's bit of a red herring. If you print out your parameters a b c that should tell you enough to continue.

how so?

Your code is wrong because you rely on approximate values to give exact answers. If your code does produce different results elsewhere then you might be on a different architechture (ARM?) and it would still be wrong even if it should happen to incidentally give correct answers, if that's even the case.

js update

• changed console.log to assert.fail
• changed failure messages so that they explain what is tested to avoid frustrating vague failure messages (this comes at the cost of making the kata somewhat easier as it removes the need to figure out the problem, but I'll take that over being vague)

the test logic remains the same but is rewritten to facilitate the clarified failure messages or because I didn't like how it looked at me

JS tests print AFTER assertion

assertion fails -> exception -> print never happens because exception exited the function early -> no information given to solver what's wrong

the python tests are also written this way but that test framework doesn't exit early on failed assertion (it should though, and it could conceivably change that behaviour)

the test code intended to print out failure messages but was written in an incorrect way that used to "work" but now doesn't (specifically there were console.log's after assertions - but a failed assertion raises an exception and thus exits early and skips code after it)

the tests have been updated, they'll now tell you what they don't like.

if you put a space wrong in the output string then it wouldn't be correct any more, that should be entirely unsurprising x)

maybe you'd argue that a space doesn't matter because a human might not see it. but some humans would see it, or it would look weird in some situations. there's also nothing special about space - the problem description doesn't mention words (or more to the point, word separators, space), and if you have logic in your code that is doing things that aren't related to the problem then that might immediately be a hint that it is not the correct thing to do. you could have other characters missing or added, ones that you would see. wrong spaces might also wreak havoc in other parts of a program that relies on disemvowel to behave correctly.

it is stated that text and numbers alternate, which it does not do in your output

it is however a problem that the tests don't consistently catch that

JS test gen does not obey given constraint:

Following this rule, each number tested begins with encoded text and ends with an encoded number.

After the text, there is a binary number.

Testing for '1051209811098120113115108121126110981198106105112122117981198116102108124981001000010010098114110120119108101121111114116'
It should work for random inputs too - Expected: 'et, 6, tmohuzj, 3, felvq, 3, pbhx, 9252, njtshauknp', instead got: 'et, 6, tmohuzj, 3, felvq, 3, pbhx, 9252'

expected answer ends in text, it should end in a number

Ruby as well:

expected: "opbkrfrpk, 542, toixqsrtx, 4, hfvzzgyiuy, 344, uvr, 7, krrk"
     got: nil

(compared using ==)

and Crystal:

Expected: "stxaifmr, 6, zqnigbynah, 6425, albief, 1098, etmf, 788, gxxbuyvc, 84, uksexpybwkyei"
     got: nil

fourth time's the charm

Issues on lua tests being flipped get closed and ignored. I guess I'll just raise it again? I'm confused, and fail to see why this would be difficult.

that's not the test that failed, your prints are misleading. if the rust tests are to be blamed in some way it's that they aren't separating the tests, which makes it easier to mix them up, and more generally that they invite mistrust by not showing what they're doing, relying instead on the solver to figure out what happened which isn't ideal when the test code is hidden

(also you absolutely should not be using f64, that would fail for large numbers since you're effectively reducing the number of available bits)