There seems to be an issue in the algorithm generating the random tests - the points provided are all out by 0.333333 or 0.666666, but the tests still expect the points to be integers:

Note that none of the expected values were in the pointsList provided, so the only way it was possible to pass the kata was by introducing a fudge factor (n => n < 0 ? Math.ceil(n) : Math.floor(n)) to round the coordinates to ingegers.

My apologies for this - I'd chosen the limits for the tests in a slightly haphazard way, which didn't take into account JavaScript's limits for large-int precision. I've now taken a more scientific approach to choosing the limits, so the maximum possible values generated should be within the limits that JavaScript can handle. Give it another try if you get a chance and it should work now. Thanks!

Currently the random tests include some inputs where the car is moving backwards (ie. the distance is greater at the second measurement than at the first), but the description doesn't define how such inputs should be handled.

The current tests expect such inputs to return a positive speed, but that can only be established through guesswork. Either updating the random tests to exclude such inputs, or explicitly stating in the description how such inputs should be handled, would be great.

Otherwise, a fantastic and practical kata - great work!

Hi BK - my mistake. I'd tweaked the code for the test cases and accidentally reverted to the old maximum values. This should be fixed now - give it another spin.

Good plan. I've now reduced the limits of the random tests to n = 100, l = 15, and that seems to have resolved the problem – the highest binomial coefficient potentially generated is now (114, 14), which is below the threshold at which precision issues start to creep in.

I've also created a single random test function, wrapped it in a loop, and increased the number of tests to 100. Give it another go - should hopefully work as intended now! Do you want to update your Ruby translation to reflect those changes? I'll approve it when it's done. Cheers!

I've changed the random tests now to max out at n = 100, l = 15. That means that the highest binomial coefficient being generated is (114, 14), which is accurate to WolframAlpha's results. I've also increased the number of random tests given, so it should still test the efficiency of the algorithm.

Give it another go and see if you have any issues – hopefully that should have sorted everything out. Cheers!

What zebulan said. On top of that, the JavaScript implementation seems to treat non-integer elements as adding 0 to the returned value, rather than returning a 0 value outright. So, for example, testing against [15,{},"Hello World"] expects a return value of 15, whereas the description implies the return value should be 0 (as you say, arr2bin([1,2,'a']) == '0').

Thanks Zozo - clearly the binomial calculator I was using had exactly the same limitations as mine!

You're right - an array of strings would be a good fix. Although it may be easier to just lower for the random tests so that the figures don't exceed JS and Python's comfort zones.

All working as expected now. Cheers Raul, great kata!

There seems to be an issue in the algorithm generating the random tests - the points provided are all out by 0.333333 or 0.666666, but the tests still expect the points to be integers:

`(Expected: '[[16, -0, 0], [-8, 16, 4], [-10, -9, -13]]', instead got: '[[16.333333333333332, -0.6666666666666679, 0.33333333333333215], [-8.666666666666668, 16.333333333333332, 4.333333333333332], [-10.666666666666668, -9.666666666666668, -13.666666666666668]]').`

Note that none of the expected values were in the

`pointsList`

provided, so the only way it was possible to pass the kata was by introducing a fudge factor (`n => n < 0 ? Math.ceil(n) : Math.floor(n)`

) to round the coordinates to ingegers.Hi Johan,

My apologies for this - I'd chosen the limits for the tests in a slightly haphazard way, which didn't take into account JavaScript's limits for large-int precision. I've now taken a more scientific approach to choosing the limits, so the maximum possible values generated should be within the limits that JavaScript can handle. Give it another try if you get a chance and it should work now. Thanks!

Best,

Steve

Currently the random tests include some inputs where the car is moving backwards (ie. the distance is greater at the second measurement than at the first), but the description doesn't define how such inputs should be handled.

The current tests expect such inputs to return a positive speed, but that can only be established through guesswork. Either updating the random tests to exclude such inputs, or explicitly stating in the description how such inputs should be handled, would be great.

Otherwise, a fantastic and practical kata - great work!

Hi Zozo - my mistake, I accidentally reverted to the previous values while tweaking the random test loop. This is fixed now.

Hi BK - my mistake. I'd tweaked the code for the test cases and accidentally reverted to the old maximum values. This should be fixed now - give it another spin.

Good plan. I've now reduced the limits of the random tests to n = 100, l = 15, and that seems to have resolved the problem – the highest binomial coefficient potentially generated is now (114, 14), which is below the threshold at which precision issues start to creep in.

I've also created a single random test function, wrapped it in a loop, and increased the number of tests to 100. Give it another go - should hopefully work as intended now! Do you want to update your Ruby translation to reflect those changes? I'll approve it when it's done. Cheers!

Hi both,

I've changed the random tests now to max out at n = 100, l = 15. That means that the highest binomial coefficient being generated is (114, 14), which is accurate to WolframAlpha's results. I've also increased the number of random tests given, so it should still test the efficiency of the algorithm.

Give it another go and see if you have any issues – hopefully that should have sorted everything out. Cheers!

What zebulan said. On top of that, the JavaScript implementation seems to treat non-integer elements as adding 0 to the returned value, rather than returning a 0 value outright. So, for example, testing against [15,{},"Hello World"] expects a return value of 15, whereas the description implies the return value should be 0 (as you say, arr2bin([1,2,'a']) == '0').

Thanks Zozo - clearly the binomial calculator I was using had exactly the same limitations as mine!

You're right - an array of strings would be a good fix. Although it may be easier to just lower for the random tests so that the figures don't exceed JS and Python's comfort zones.

Thanks both. I checked the example Zozo gave, and the expected values are correct, so there may be an issue with your implementation.

The first two values at which Zozo's solution diverges are the binomial coefficients (84, 16) and (85, 17) - entering them into a binomial calculator will return the expected results: http://www.calcul.com/show/calculator/binomial-coefficient?n=84&k=16

Thanks smile, very good point. I've added in random testing now - give it another try!