It might never been encountered in your solution if you pre-check if indexes are positive but there’s a potential source of error because of this subtle difference:
int(-0.5) = 0
math.floor(-0.5) = -1
1 Like
I compare to the indexes then I truncate if necessary.
most likely you are using elif, but you should if if
I was using math.floor and not rounding down with int.
After getting in touch with the puzzle creator, I got to know that I over complicated the math and hence it was failing… after changing it to simple math it worked 
Thanks for the suggestion though, and I know its hard to comment on some else code without seeing it. Its a blind shot.
1 Like
Hey thanks for your reply, but its altogether a simple fix 
the “A” one because its says : A being the closest and Z the farthest from your observation point
wow, enjoying , 
Couldn’t solve it, is this really an easy puzzle!? I can’t figure out how to implement the time difference correctly. My current solution works when the time is sequential, i.e 1, 2, 3 but breaks when it’s something like 1, 5, 6.
It seems your problem is about Math, not with coding. Look up tutorials about Ratios and Proportions. This puzzle is easy because it involves only linear equations.
The only troublesome factor may happen when you have to simplify float-point numbers into integers.
2 Likes
Try to solve small examples on paper first.
Try to solve this one:
t1, t2, t3 = 1, 5, 8
x1, x2, x3 = 2, 14, ?
y1, y2, y3 = 12, 4, ?
Hint: for dt = 4 you got dx = 12, what would be the dx for dt = 1? And for dt = 3?
3 Likes
Hey! Completed all the tests but it still report me that test 10 is missing when I submit, any clue? I would like to ckeck others (and cleaner :p) solutions 
Thank you!
Maybe a rounding issue?
When computing the speed, are you using euclidean distance or are you computing it for each axis separately ?
Alright so after receiving several complaints about Validator 10 I have decided to update the contribution.
It appears Python users who decided to compute the speed using the euclidean distance got an incorrect output for Validator 10 because of the imprecision added by the square root.
I did not plan for this mistake so only the validator featured a case where rounding could be an issue. I have added a similar case in the corresponding test case so that hopefully players will be able to spot their mistake.
Sorry for the inconvenience this may have caused.
1 Like
I’m using Javascript. My issue is that the validator 10 is green in IDE, but when i want to submit my code I still get 90% and validator 10 is red.
I’m gonna try the euclidean distance, thank you for the clue
What you see in the IDE are test cases, not validators. Those are not visible to prevent hard coded solutions so, in some cases, it is possible to pass all test cases but not all validators.
Please read my post above, you should avoid using euclidean distance as this will just add imprecision and may result in a rounding error.
1 Like
I used Python and everything worked fine.
Someone sent me their code and they did a bunch of extra steps which resulted in rounding errors, but only on Validator 10. It seemed to affect other people too so I figured editing the contribution to make Test Case 10 more consistent with Validator 10 would be a good thing. But of course it’s hard if not impossible to predict every single mistake someone can make while solving a puzzle.
i don’t understand what do you mean by " the final coordinates are to be rounded-down"?
It has a commonly used function name floor(), existing in many languages.