Lua translation!

python new test framework

I found the instructions very confusing.

I'd simplify it by saying that a good char is in the same column or row of buttons as the previous char.

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

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})