Getting the right floating point precision is tricky in some computer programming languages, namely PHP the one I used for this, depending on which ones you're using indeed, there are also some specific modules dedicated for that making it easier like in Python I guess.

Mine looks the same, but your basic sorting is more advanced.

My solution is 'wrong' in some cases for 1 number. I have been testing this solution and its right! Its seems that the problem lays on the rounding used on the tests.

function calculate_scrap($scraps, $robots): int {
$tot = $robots * 50; // total iron needed, not the brute.

foreach ($scraps as $perc) {
$tot = ($tot * 100) / (100 - $perc);
}
return round($tot);
}

Kata description should be made language agnostic

python new test framework

nice

should be top solution

Even if intermediate imprecision is avoidable, the kata may invite such imprecision, or it may be too much to ask of solvers to avoid it without a specific mention in the description.

Note that your solution uses / and Math.ceil, which means the answer might now be off by one instead of off by a very small number, and the tests do not make any allowances for that.

Floating point operations are inherently imprecise, and the only way to deal with that is using approximate comparisons; any rounding has the possibility of introducing errors.

But I'm still not reopening a 6 year old Issue.

I was referring to using only intermediate rationals, yes. Looking back at my solution, in fact, I seem to have used only intermediate integers.

Working in python, it seems that the test has integers inside nested lists.

''' The content of a dictionary item is not correct: [42740748] should equal [[42740748]] '''

This is also causing a TypeError, can't compare 'list' to 'int'

Looking at the rules and examples, the result should be a list of ints, not a list of a list of ints.

Approved

python new test framework is required. updated in this fork

Type error in description

// result should have this content: {"A": [1, 3]}, "B": [2]}

I think you are wrong ( unless you use intermediate rationals instead of floating point numbers. but JS has no native rationals ).

But I am not reopening a six year old issue.

Issue resolved at some point in the past; tests now compare only integers and an integer solution can be calculated with no floating-point intermediates.