okay, it seems that the translator fixed the original translation, but this has no effect on the kata. i guess this is the reason for the useless double use of Math.abs()

I cannot approve yet, the author is active :(

gotta wait 7 days...

It seems that you edited this fork post-approval to fix the issues i raised. I'm letting you know that this has no effect on the kata; post-approval you need to either use the edit button on the kata, not the translation to enter the kata editor, make your changes and re-publish the kata; OR make a new fork (preferably using the kata's fork button since it pulls the up-to-date version, instead of forking the translation that may be obsolete) and submit it for review/approval.

I know it's confusing, and it's an oversight that Codewars allows us to edit a fork post-approval since it's useless and confusing, but that's the way it is.

Might not be perfect but the sooner we can fix it the better

• sample tests do not compile (missing List import)
• the criterion for odd numbers incorrectly classifies negative odd numbers as even numbers

Fork with following changes:

• Scrutinized tests with order and name annotations

• Added useful assertion messages

• Changed input from double to int to comfront with description:

  a and b are integers and > 0

• Updated to latest version (Java 17.0)

Hello, thank you for the Java translation. I would like to approve your work, but I get the error message "Description cannot be approved, recent changes from related record must be merged first."
Is it because of the changed description? How can I accept the changed description?

hi, sorry for the massive delay. can you add the new sample test changes for string ops? this looks good for a merge otherwise.

• There are no real random tests which convert ranedom inputs from a randomly chosen alphabet to another.
• //TODO can be removed from full test suite.
• Please use JUnit 5.
• In initial solution setup return something (e.g. null or empty string) to make the setup compile.

Approved

• Fixed tests should contain more edge cases, e.g. 1, -1, Integer.MAX_VALUE and something like Integer.MIN_VALUE + x.
• Java has a Random class with proper API. No need for JS-y Math.random()*a+b.

Nice job! i solved it in a similar way.

Hi.

I made a change to ensure that an error of 1E-10 or less is considered valid.
There was a small chance that it would not pass in the tests or your solution.

return Math.abs(width - height) < 1E-10 ? "perfect" : width > height ? "fat" : "thin";

instead of:

return width < height ? "thin" : width > height ? "fat" : "perfect";

I made these small changes because there were times when, even though the square roots were in the same direction in both cases, the test didn't match those roots within the margin of error and gave a slightly different result. This change fixes that, and in 100000 tests performed, there is consistency.

Best regards.

Why do I think that's not 6 kyu? I think it is 4kyu.

Elegant solution, me likes this

I just edited it myself and also updated to JUnit 5.