I was getting off-by-.01 errors off and on even after increasing granularity to 1e-3 and rounding to 1e-2.
Perhaps you should allow values on either side of a local minimum.
Either that, or specify exactly what should happen when approaching a minimum. That's a can of worms that's not worth it, I think.
Firstly, thanks for the advice btw! :)
So I went with making all outputs number type as it seems more appropriate for the question.
I've actually removed the flat line case from the description as it is trivial (using gradient descent there shouldn't be an issue). However, I've still left an error message in the test cases as people may use an unexpeceted solution.
(I think) it's all fixed now!
Sorry I will resolve the issues now! :)
Returning inconsistent datatypes is not a best practice.
If you wanted to know whether or not the ball rolled, you'd need to compare the input and the output. But now, if the ball does not roll and you want to know the output, you also need to consider the input anyway. So it does not really make things more complicated, but it does make them more consistent.
Using inappropriate datatypes is not a best practice either.
If a value is a number, it should be a Number, not a String.
Please await confirmation before closing issues.
Stringifying numbers does not make this issue go away. An x-coordinate logically is a Number, not a String.
It's actually consistent. The return value are all strings.
The sample tests expect number to be returned though. See above issue.
You're doubtlessly correct. That word is completely new to me.
( Never did maths in English .. )
No, it's quartic. 4th order polynomial, not 2nd order.
Sample tests expect a number to be returned but actual tests expect a string to be returned.
(To maintain consistency I'd suggest changing the sample tests.)
Spelling erorr in title: *Quadratic
Another one in third sentence of Problem: *coordinate