I remember not being able to come up with a test case for this. As far as I can tell, you get the same result with either type of division because of the integer division in the top-level calculation. Consider the following scenario:

• Calculating score for Tyrannomon (stats are HP + defense)
• HP is 2999, defense is 150
• Carryover score is 0
• Stat count is 2 (HP + defense)
• Carryover count is 0

If we divide the HP "wrong", we get:

((299.9 + 150) + 0) / (2 + 0) = 449.9 / 2 = 224 /* 224.95 rounded down */

If we divide the HP "right", we get:

((299 + 150) + 0) / (2 + 0) = 449 / 2 = 224 /* 224.5 rounded down */

If there were another decimal in the calculation, we could get a different result, but:

• HP is the only stat that gets divided by 10 (MP exists in the game and gets the same treatment, but none of Agumon's digivolutions need it).
• All the other values in the calculation (non-HP stats, stat count, carryover score and count) are integers.

Anything I'm missing?

This should be fixed now.

Needs additional fixed test cases for matching falsy values with {}:

I've added NaN/false/0/'' tests under "Object tests". The null/undefined cases were already there.

Also needs more tests for Sets:

I've added those test cases.

Stringify function is incorrect for Set: it stringifies Set instances as Set([]) instead of new Set([]), so the stringified value will always throw an error. Other primitive wrappers correctly contains new.

Needs additional fixed test cases for matching falsy values with {}:

testXMatchesY({}, NaN);
testXMatchesY({}, false);
testXMatchesY({}, 0);
testXMatchesY({}, '');

testXDoesNotMatchY({}, null);
testXDoesNotMatchY({}, undefined);

Also needs more tests for Sets:

testXDoesNotMatchY(new Set([]), {});
testXDoesNotMatchY(new Set([]), []);
testXDoesNotMatchY(new Set([]), '1');
testXDoesNotMatchY(new Set([]), 1);

If one of those is HP, only 1/10th of Agumon's HP is used

This 1/10 uses integer division too, right? This can lead to different results in very specific edge cases, which should be clarified and (IMO should be) tested. The current edge cases doesn't specifically test for this part.

thx. fixed

Thanks for the advice, fixed!

Giving hints is not even that necessary I think, but don't force people to Train to see examples.

Give the example tests in the Description.

Thanks for the advice, having looked at the task with a fresh look and realized that it is very difficult. I have updated the description of the kata, and I hope now it has become a little more clear how to solve it

I think this could be improved by giving more information about what the puzzle is in the description. I had no idea what I would be looking at until I hit Train.

The wording for this is now "null matches if the input is null".