[Community Puzzle] ball trajectory predictor

Coding Games and Programming Challenges to Code Better

Send your feedback or ask for help here!

Created by @RedYou,validated by @P4V3L14K0V,@Rouge_dragon and @fungi_star.
If you have any issues, feel free to ping them.

1 Like

I don’t agree with RedYou’s answer.
A direct calculation of the number of steps gives:
Test1 400.0
Test2 565.6854249450247
Test3 226.27416997800984
Test4 1045.967407786875
Test5 102.03388449411928
Test6 2614.9185194671873

Since the text says “Number of whole steps (ceil)…”, I assume we need to round up the first number. In the case of test2, 565.6854… does round up to 566, so that seems fine. However, whether using 565.6854… or 566 in the subsequent calculation, no intermediary rounding or absence of seems to yield 0.22 as the y value. The true value is much closer to zero.
What am I missing?

The answers are:
Test1 400
Test2 566
Test3 227
Test4 1046
Test5 103
Test6 2615
The statement tells to round up (not down :expressionless: ).

Actually you must use ceil(delta_t) to calculate the final y, which is not very clear in the description.

Also, the conventions for axis and direction should be specified.


In test2, if I use 400 and 566 to calculate y, I still don’t get 0.22.
Using 566 and the angle instead gives me the same answer, which is interestingly very close to 0.22 but outside the screen.

Maybe try to forget the horizontal walls and calculate the rebounds at the last moment.
With dt = 566, the overall dy is 400.2224381486049.
As the initial y is 400, the final y would be 800.2224381486049 if there was no horizontal walls.

Rebound, it is. Thanks pardouin!

But why if t=565.6854249450247?

Apparently, we need to use the rounded value when calculating the second figure.

On the test bench, my code passes all tests, but fails 2 tests on submission. What am I doing wrong?
Thanks in advance!

The puzzle should be a bit rewritten, I think.


This puzzle doesn’t seem related to coding challenges. It is more of an exercise of guessing how to round the values in intermediary steps.
My C# code fails the last test if I use the C# Sine function. However, if I use the Microsoft Excel Sine function instead, the resulting number is accepted. The only difference is the number of decimals kept by Microsoft Excel (the function outputs differ starting from the 8th decimal).
This is one the two worse puzzles I have faced among the two hundred or so I have worked on.

Personally I don’t mind geometry problems with little actual coding.
The real problem with this puzzle is the lack of specification.

I don’t understand your last post, you only need 2 decimal places so who cares what happens for the 8th decimal?
Maybe you’re using the sine function at every step and the errors accumulate? If you do so, try to refactor your calculations so that you use the sine function only once.

1 Like

I just changed the float type in the starting code to double type (for the angle) and the Sine function now yields a “better” number, enabling all tests to pass.
Unfortunately, validator 2 still fails.
Since I have no way of knowing why it fails, I guess this will be my first puzzle I have to give up on.
Thanks again for your help, though.

Validator 2 has an angle greater than pi/2, so the cosine is negative.

And there’s no test with such a case. :angry:

And neither is there a test case where x <> 0. But I suspect that there are two such validators.
Thanks again, pardouin. Your hint enabled me to complete the puzzle.

C’mon guys. Are you suggesting that a far from perfect contribution has been approved? Seriously? With the awesome moderation system we have? Tss… :roll_eyes:

1 Like

Recalling substandard products is one of the built-in functions of the awesome moderation mechanism. Not bad we have a showcase to demo how the mechanism works.

1 Like