and i thought my was long, urs are ridiculus LMAO

It might've been harder in the language it was originally posted in.

ceil(infected / total * 100) is not guaranteed to equal ceil(infected * 100 / total)

Which means that at least one of these is wrong. And how am I supposed to know that wrong results are acceptable? While I don't like approximate comparisons where there are unnecessary anyway, the main issue is that this behavior should be specified. How should I know not to overcomplicate my solution when imprecision is acceptable? Or how should I know where not to raise the issue? How about Fibonacci numbers by exponentiation? Should I raise an issue if the tests don't accept my double-precision floating point results because they have "rounding issues"?

As a side note, if too many users have troubles with floating point errors, that's exactly because their errors have been accepted way too often to get used to it. Normalization of deviance.

Ok, cheers!

Use print for that, you can have as many as you want, and only return the expected data type.

So... I want return all my steps, that easier...

Your code is returning a wrong data type:

percentage = 100*11/15 = 73.33333333333333 <- that's a number, not a string.

There're no issues with the tests.

Python

Pls, remake the tests! I am just writed:

def infected(s):
TAB return s

TypeError: bad operand type for abs(): 'str'

What???

So easy for 6kuy

It's far too easy for 7kyu

Oh, that's 7kyu? No-no, only 9kuy)

Prolog translation kumited.