... oh, that would do it. I didn't know that hex was a built-in, so I had this defined globally:

hex = "0123456789ABCDEF"

Thanks for the help!

Please, post your code in a comment with a spoiler tag. The only reason I can think of why this is happening is that you're overwriting some functions globally.

Thank you! I've learned something new about the split function, so this was a good exercise. It was just unpleasantly surprising to see this test failure that I didn't expect.

Description says:

Input
a string strng of n positive numbers (n = 0 or n >= 2)

Nothing is said about trailing spaces or not. You could have simply taken a split function without separator. Nevertheless I added such an example in "TEST".

The random tests in Python could contain trailing spaces, e.g. "24 4820 10380 21 259 1 "
I didn't expect this, and nothing in the description or the standard tests led me to expect it. It could be nice to add a specific test case for it.

Consider the following use case: represent the chance of winning visually with 1% corresponding to 1 pixel. Then it is natural to require to round down results. And it is desirable to compute all values as precisely as possible to avoid visual glitches.

Another example. Consider this kata about solving differential equations. It seems like it does not have any rounding requirements. But in fact, rounding requirements are there for the number of elements in the output. In general, rounding is unavoidable for many floating-point computations.

My position can be summarized as follows: If a problem is well-defined mathematically and if it is not very difficult to compute the final result precisely, then approximate equality should not be required.

Sorry, I missed the second part of your message. You are absolutely right that more tests are necessary to eliminate approximate solutions. Unfortunately, it is not possible to test cases like 82.999999998859% because they require very long input strings.

The problem is well-defined mathematically. Floating-point numbers are not mentioned anywhere in the description. And it is possible to solve this kata without them.

Moreover, in many real-life situations floating-point numbers cannot be used directly. Final results have to be rounded to some integer (or even boolean) values. That's the point which this kata tries to teach (at least that was my motivation when I approved this kata).

i don't think the value is 66 but it appeared that way, that's why i found it weird, in the attempt appeared 60 and I could pass

The rounding requirement is a bit out-of-nowhere. Looking at the other solutions, a lot of users deal with it by multiplying the result by 1.0001 before rounding, or similar tricks.
Is that the intended answer? It seems less interesting and less correct than the version which sometimes returns 74.99999999999999 instead of 75.

If you want us to learn how to handle such edge cases correctly, it would be worth adding a few test cases that specifically check that. Where the correct calculation should give, say, 1455393541/1753486194, which is 82.999999998859%, and the correct answer would be 82. Solutions that simply add a fudge factor would give 83.

Thanks! I didn't notice the distinction between beta and draft.

This kata is in draft state, and you cannot submit solutions to it.

I think I have a working solution to this kata, but it's a bit lopsided and I'd like to submit it so I can see what everyone else did.
It passes the server test cases, and a popup invites me to "take your time to refactor/comment your solution. Submit when ready." - but the Submit button doesn't show up. It still reads "Attempt".
I've not tried beta katas before, so is the process different for these?