This is a fantastic kata. I saw it as an opportunity to brush up on recursion and data structures.

I have forked my rejected Java translation and reworked it here: https://www.codewars.com/kumite/62b37def10340c442db4bd7c?sel=62bc8437044fff000ffb33b1.

This seemingly straightforward challenge runs into inherent problems, because:

• Binary can't precisely store some decimal values
• Java data types generally cannot store irrational numbers without some loss of precision
• Coders may complete the task with a novel order of operations that differs from those employed by the author. Inherent loss of precision may well lead to an equally valid result that differs from the author's.

I have opted to modify the test assertions to accept any resulting running pace that falls within one second of my answer (a one-second margin of acceptability).

Hmmm...these all are very advanced considerations (yikes! for a "basic" kata). I've experimented with Apache Commons Math 3.3 BigFraction as a silver bullet. That solution just seems to delay the inevitable challenge of converting an irrational number to one that conforms to the string output of the kata. There, too, an order of operations biases the result when converting the fraction to a Java primitive. Conversion of BigFraction to BigDecimal may yield java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.

How about I leave the kata's method signature as is and accept a one-second tolerance in the result? Trade-offs abound here (existing difficulty rating, approved translations, and accepted solutions).

But that's not my Java solution to the kata. When I run my tests with csv input parameters "1.0,55:06,55:06", my solution passes. I've run 100s of thousands of random tests and believe it's always passing.

Approving one's own translation should be avoided, right? Or is that the de facto standard (with an eye on speed to market)? Thanks.

Greetings. I have solved many, many kata but never translated one. I humbly submit my first Java translation for consideration.

Myself a runner, I perform this calculation almost daily with a basic calculator. I could not resist the temptation to solve it but found my language of choice was not an existing option.

Inherently random tests require a solution so as to compute the expected outcome at run time. Is it typical for authors to provide an alternate solution for the random tests as a safety precaution (a built-in quality control)? That was my take and the route I chose.

Thanks.

My goal one day was to find the 6 kyu kata with the lowest favorability rating and solve it. I did solve it and can't understand why the rating is so favorable at ~60%. The lack of details on the expected formatting (gaps in the result) makes this a much more complicated task than it has to be. I'd say the guesswork on embedded spaces itself is about a 4-5 kyu problem. Since you must complete the easy 6 kyu problem and a sinister documentation problem, this is two challenges warranting a higher complexity rating.

I recommend adding more test cases that attest to the intended output with some meaningful variability in the inputs. I also recommend stating the requirement that the lines in the output follow a rule of fixed width with alignment of the least significant digit in the three columns.

It's frustrating to lose much productivity just because the unit test has reversed expected and actual outcome arguments.

This exercise was quite enjoyable, and for that I thank you. It was indeed easy to overlook the detail "a valid response word must contain four different letters". Was there a test among the provided sample tests that demonstrates that requirement? I think that was missing, so I'd suggest adding one to the standard. Also, it seems like the word "different" is problematic in English. Maybe the requirement could seek four "unique" letters. I don't understand the real-world reason for that nuance in the exercise; the reason why (other than possibly to add one more nice twist for complexity) could be elaborated a little in the description.

Thanks again for the kata and the very recent translation that revived activity on this!

I've gotten lots of traction from Manning's Modern Java in Action.

Loved this little challenge. There was a Java issue with test compilation b/c of the mismatch between the method's signature requiring a String seed but the test feeding it a char argument. Looks like someone has already addressed the issue. Nice contribution!

I love katas like this to start my work day. It is not too tough but forces you to exercise multiple coding skills that are not too esoteric to apply in the course of normal technical delivery.

Love it! Your solution follows my line of thinking but is more streamlined.

Brilliant! I always overlook reduction, but here it is exactly the needed strategy.