I've got a Rust solution which failed the "num" crate check, since I used the div_floor function from there. Thought only num::BigInt was disallowed. No matter, I removed the dependency, and it still failed the crate check, so I removed all dependencies (itertools) and it still fails the crate check. I reset the environment with the button at the bottom, still fails. I don't know what to do now. Any ideas? I'm guessing the crate is still installed somewhere so the test is failing.

python new test framework is required. updated in this fork

python new test framework is required. updated in this fork

In the PHP version, the random tests will occasionally pop up an empty string instead of a number, combined with an error:

Undefined array key ""

Stacktrace that is supplied with the code goes to the tests, not to the kata-code:

/workspace/default/tests/AddFunctionTest.php:68
/workspace/default/tests/AddFunctionTest.php:53
/workspace/default/tests/AddFunctionTest.php:145
/workspace/default/tests/AddFunctionTest.php:30

My code handles empty strings as zero, but the tests still fail, as an exception is thrown.

In PHP:

• No sample tests

• AssertSame should be used

• Usage of class and method is redundant and should be removed

Decimal numbers are used in the kata, which means floats are not the correct data type for this. The returned result should definitely be a string (or a big decimal, but in JS this is complicated).

Rust translation ready for your approval: https://www.codewars.com/kumite/64469a35b8feca00195e995d?sel=64469a35b8feca00195e995d

Adding all kinds of edge cases and different types of input, should be part of the sample tests aswell. This makes the kata less annoying.

Update to JS Node 14.x: https://www.codewars.com/kumite/639be9febde94df169ba37cd?sel=639be9febde94df169ba37cd

Update to Node 14.x

The kata does not rule out, or properly handle the case where all workers of lowest capability is used, but there are still work left. For example:

dimension: {
  length: {value: 111, unit: 'm'},
  width:  {value: 1, unit: 'm'},
  height: {value: 1, unit: 'm'}
}
work: 111m3
workers: {
  a: {value: 100, unit: 'm^3', number: 2},
  b: {value: 2, unit: 'm^3', number: 5}
}

Every solution, including author solution, returns {a: 1, b: 6} instead of {a: 2}, which is absurd (there are only 5 bs).

Another kind of edge case the kata does not handle is when the greedy algorithm is stuck at lower tier workers, and should fall back to adding a higher tier worker:

dimension: {
  length: {value: 111, unit: 'm'},
  width:  {value: 1, unit: 'm'},
  height: {value: 1, unit: 'm'}
}
work: 111m3
workers: {
  a: {value: 100, unit: 'm^3', number: 2},
  b: {value: 2, unit: 'm^3', number: 1}
}

Every solution, including author solution, returns either {a: 1, b: 2} or {b: 2} (???) instead of {a: 2}.

For a even more comprehensive edge case test, try this:

dimension: {
  length: {value: 156, unit: 'm'},
  width:  {value: 1, unit: 'm'},
  height: {value: 1, unit: 'm'}
}
work: 156m3
workers: {
  a: {value: 100, unit: 'm^3', number: 2},
  b: {value: 10, unit: 'm^3', number: 1}
  c: {value: 9, unit: 'm^3', number: 1}
  d: {value: 8, unit: 'm^3', number: 1}
  e: {value: 7, unit: 'm^3', number: 1}
  f: {value: 6, unit: 'm^3', number: 1}
  g: {value: 5, unit: 'm^3', number: 1}
  h: {value: 4, unit: 'm^3', number: 1}
  i: {value: 3, unit: 'm^3', number: 1}
  j: {value: 2, unit: 'm^3', number: 1}
  k: {value: 1, unit: 'm^3', number: 1}
}

(Expected result should be {a: 2})

Description:

You are to return the optimal number of workers that will be required. That is, you have to make sure you use the maximum number possible of workers with higher capabilities before moving to workers will lower capabilities. But if the work to be done is too small even for a worker with the lowest capability, you have to use a single worker from the lowest capability to complete the work.

This paragraph is describing a greedy algorithm (and the kata expects a greedy algorithm), which is not optimal.