I think something generic like “Note: Use (any) floating point operations at your own risk” at the end would be helpful in any language just as a pointer to those individuals who may not fully realize that floating point calculations are a compromise.***
The way I see it, there is not a single right way to solve this issue.
The exercise is meant to be solved in an optimal way which has less to do with coding in any particular programming language but more with problem solving within the capabilities and limitations of most current computer hardware.
The “cute background story” is a bit of a distraction
- You are supposed to realize that each of two competitors for the purposes of the problem can be represented via the distance as a linear function of time (from the point of view of the delayed competitor). By equating the functions for both competitors and solving for time you are doing most of the “hard work” up front.
- You are supposed to be paying attention to the “types”(, units) and the required precision of the problem. The required precision is exactly down to a whole single second - all the inputs and all the outputs are specified as integers. (Type awareness can be a bit of an issue for people used to dynamic languages or languages with type coercion).
- Equipped with the right formula and the realization that all quantities are integers you are supposed to take a good, hard look at the calculations involved to see if there is an optimal way of organizing the calculations to minimize or possibly eliminate any possible loss of precision. So in fact the author’s solution that uses only integer operations organized in such a way that sub-second precision is knowingly sacrificed only once is optimal.
is a guess game at which algorithm the author used
No - it’s realizing how to design an optimal solution given certain constraints.
It is my strong opinion that many of the solutions rejected by the random tests were in fact valid
No - the exercise falls flat because of it’s reliance on random testing that can occasionally pass suboptimal solutions.
The typical response would be to increase the number of random test from 50 to 500, 5000 or more. However that would significantly increase the load on the exercise server.
What would make more sense is to “slightly sabotage” the optimal solution (by using one or two floating point operations in the typical fashion) and use random tests to discover the cases that tend to fail suboptimal solutions and to collect those into a suite of static tests (acting more or less as a suite of regression tests).
***PS: Or simply state “this exercise is looking for an optimal solution, not just one that is good enough.”
