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.
n => n < 0 ? Math.ceil(n) : Math.floor(n)
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!
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!
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!