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.

Edges and corners use their own values as the neighbors.

I don't understand the examples you give. Can you explain?

Hi again,

You may want to change the description, saying clearly that if the kernel grid will always be 3x3, this is not the case for the image.
This is not really problematic, but at the beginning I assumed it would be the case for the image too and I had to change the way I constructed the loops (not really funny to have to go "back and forward" in the algorithm).

Second point : the output of the assert tests is a bit confusing when the code fails : it does not apply the string formating (the line feeds are displayed as \n).
If you want to display correctly the output, you could "double check" the tests :

• Evaluate the warrior's code and store it
• check against the expected array : if different print it
• then feed the assert test

What do you think ?