python new test framework is required. updated in this fork

In the Java version, the given basic and other unit tests have the assertion parameters in reverse order.
The expected value must be the first parameter and the actual value the second parameter.

python new test framework is required. updated in this fork

Scala translation

At the moment it's not good.

1. "01:03, southern hemisphere, should be equal to 00:01". I think this is incorrect.
2. "12:24" is not the same as "00:24" - if we are talking about the direction of the hour hand, then, I'm sure that this is still the same thing.

Initial solution in crystal should provide input type of seed

Ruby 3.0 should be enabled.
Description should use KaTeX.

The actual and expected values in the random tests should not be stringified.

There should be random tests with small inputs for easier debugging.

Hi, nice kata, but I'm seeing a few issues, either with the randomised testing or perhaps the description.

1st problem

Wrong answers!?

Example:
During random testing, when calling find_north('05:00', 'South').

We would expect North to be half way between 00:00 and 05:00, so I'd expect 02:30, but I'm getting this message: '02:30' should equal '02:00', which is the answer I'd expect for find_north('04:00', 'South') or find_north('08:00', 'North')

2nd Problem

Rounding errors, or maybe an unusual rationale for applying rounding that is not described in the instructions.
When we have an odd number of minutes we need to make a decision on whether to round up or down when we halve the current time to closest way to 12:00. I've both tried rounding up and rounding down, but neither passes consistently. Is there a more complex rule for rounding up/down? Down before 6:00, up after 6? Down for *:00 to *:30, up for *:31+? Some combination of both!? :)

Here's the output of a pair of the random tests:

1. Calling find_north('05:41', 'North'), I see '08:51' should equal '08:50'
2. Calling find_north('12:37', 'South'), I respond with '12:18' and see 'Test Passed'

It would make more sent to me if we just appended ':30' for our 30 seconds rather than rounding.

3rd Problem

Output formatting. How do we make the decision on representation of '00' or '12' hours? Both are logically the same, but again I see examples and coutyer examples for both options.

Examples:

1. Basic southern hemisphere Tests - find_north('12:00','South'), I reply with '12:00' and see Test Passed
2. Random tests - find_north('01:45', 'South'), I see '12:52' should equal '00:22'

description is incorrect/misleading:

• if the calculated number of representatives is less then the requirement the first zones with the fewest representatives get an additional representative
• if the calculated number of representatives is more than the requirement the first zones with the most representatives lose a representative

Modifications have been made, but the description lacks the informations about the rounding rules. How are we supposed to know what to do?

After fixing the issue below, I suggest to make the kata a bit harder, because this way it's very easy (basically just completing a simple function). It's just an interesting concept a little bit "wasted" this way. You could:

• make the user write the whole class from scratch
• define M at initialization
• try to find another "twist"

Oh, and definitely, it needs more tests!

You gave the solution in your example test cases!!! D:

You also might want to specify how exactly we are to normalize the value to be within [0, 1]. Incidentally, your solution will only ever return 1 of 100 unique values: [0.0, 0.01, 0.02, 0.03, ... , 0.98, 0.99] -- not quite how the PRNG should behave. May be better to just divide by M. Of course, you may have done it that way to ease testing, which is fine. But either way, it should be stated clearly in the description.