Fixed by OP

Approved

python new test framework is required. updated in this fork

Python: Random tests are vulnerable to input modification

Kata should mention that either you don't have to worry about rounding specifics and to just use builtin rounding for your laguage, or the rounding behavior should be language agnostic and specified. The current lack of specification is unacceptable.

mmh, interesting, thx.

Ok, let's wait for more opinions.

It's in the IEEE standard, so there must be some meaning behind this (along with NaNs, Infinities and signed zero).
https://en.wikipedia.org/wiki/Rounding#Round_half_to_even

By eliminating bias, repeated rounded addition or subtraction of independent numbers will give a result with an error that tends to grow in proportion to the square root of the number of operations rather than linearly. See random walk for more.
However, this rule distorts the distribution by increasing the probability of evens relative to odds. Typically this is less important than the biases that are eliminated by this method.

I'd like to hear from the (semi-active) kata author first. Otherwise I'm not sure... After all, it's the Python translation that introduced this inconsistency with what was expected in other languages.

mmmh... :/

Q: why the fuck languages implement such weird rounding behaviors, rather than what is usually done IRL? (meaning, round up in case of ties) Is there a reason you know about?

So, what do you think?

• keep as is because the rounding is explained in the description of the python version?
• back to the original version (which doesn't make sense, to me...)?
• tweak the random tests to avoid the edge cases?

In JS, the original language, there are no such fixed tests and the random tests almost never generate these cases. The reference implementation uses default rounding, which is to even numbers in most languages, which maps to rounding *2.5s and *7.5s to *0s in all cases; and there're no negative numbers.

Is that a problem only with python default behavior? Let me reword this: in any other language, what is the expected rounding in these cases? above only? or just as messy as python rounding default method?

Or do other languages accept both answers?

Note that I added this (for python users only) in the description: Roundings have to be done like "in real life": 22.5 -> 25

My first solution did not pass due to the solution expected. That was why I added the sample test to clarify it. Now my first one passes the tests but the 2nd one fails as expectation got changed. Not good to have it in terms of consistency of kata.

The behaviour for numbers exactly between two multiples of 5 still isn't correctly specified.

It only says "to a nearest number", so there's an issues with the description. And since it's "to a nearest number" rather than "the nearest number", it isn't even ambiguous, it directly allows returning either.

I corrected the test so that rounding is consistent with the "real life process".

Since I know you won't ever do it yourself, I did it.