This is still not fixed.

Likely intentional.

I don't consider ranges inclusive/exclusive/whatever by default. In this case there's an example in the description:

>= 0 and < 10

I don't remember if it was there in the beginning, but there was something like this for sure.

Range is inclusive of lower bound and exclusive of upper bound. You disagree?

Ah, yeah. When I was trying to publish it was when things were bad.. I was getting about 10% success rate lol.

Glad you weren't too frustrated hehe. I always try to make it so users won't end up really irritated. :)

Hadn't considered that about the concurrency... I guess that could be true? But concurrency isn't the same as SMP/parallelism, I wouldn't really consider it cheating.. and JS has async capabilities on CW, right? Hm. Either way it's frustrating :(

what language?

Hehe, thanks for the updates ;)

Truthfully I think the real solution might be to change it to the top 8 or something if it's really a huge problem. Did you really have that many timeouts? :(

Do you have any ideas on how to introduce concurrency into the equation?

Fixed both issues (input mutation breaks random tests, and now results are rounded to 10 decimal places before comparison)

Edit: Now applied to all languages

There's also a more pressing problem: Random tests break if input is mutated.

Did you mean 0.1 + 0.05 != 0.15?

The description says:

The function new_avg(arr, navg) should return the expected donation (rounded up to the next integer)...

Thanks #SaladFork - I have amended the description to remove the ambiguity

Added to description