Launch to Orbit automated
Back to General discussions forum
Hi Rodion,
Thank you for the 'Sputnik' problems.
Submitting a pilot program, I get the following error message: End of trajectory is not horizontal (error -0.881219 degrees) for goal H=370 V=8700.
Testing the same pilot program via the BASIC button, I get the following output from the provided BASIC program:
H: 374875 V: 8602 direction error: -0.38121924984468 degrees.
The angles are clearly different.
Interestingly, they are different by 0.5.
I assume this comes from the following formula: err * 180/pi + 0.5
which translates the radiant error into a degree error but adds 0.5.
My guess is that the checker does not include this +0.5 element,
but I am not entirely sure where this part comes from anyway.
Maybe it's a leftover from previous int(<something> + 0.5) rounding.
Somehow I feel the +0.5 should be removed in the BASIC code (even though I've used it so far to match the logic).
Mathias, Hi! Thanks a lot for checking this, and for your attentiveness which allowed to have it fixed very quickly!
Blame on me! It is exactly "leftover from previous" version of the code which printed result rounded. The checker uses
the copy of the code with minor modifications and I perfectly remember when I spotted this dangling +0.5 and removed
it but seemingly forgot it in the published code for both problems.
I'm much sorry for I see failed attempts by you and Clive :(
P.S. to clarify - the code in the checker didn't have mistake in both problems, so it was not altered.
Thank you. Now the outputs agree. :)
There might still be an issue with determining the pilot program: My version worked and passed the test cases (though I doubt it works for the whole range). I then added comments to make it more readable and it still runs on the website but now submitting leads to Execution failed, please check your code or notify admin.
Well... checker hides specific error (to prevent possible "reverse-engineering by error messages" - though perhaps it is unnecessary) - but the failure is about execution limit reached.
I modified the checker to catch and show such situation specifically. However of course it is not good
that rem statements are included in execution (especially in counting). I'll try to take care of it. Sorry
and thanks for sharing this interesting discovery!
Interpreter for basic is improved now to strip REMs before execution, it is somewhat better now. Regretfully I inadvertently submitted your correct solution for testuser %)
A few comments to encourage more people to try this problem.
- The experiments and calcuations can be done in a language of your choice (Python for me); tranlation of the logic to BASIC is only really required at the very end for the submission.
- My solution fails more extreme edge cases. However the test cases are randomly chosen, so there is an element of trial and error.
- Try to alter a simple flight program to see how one can achieve different heights and velocities.
- Visualising the path of the rocket for some example cases really helps to understand what's going on.
- You can try to chose your actions from scratch at every given time point in your program, or you can follow a pre-determined plan based only on target height and velocity. Or a mix of these.
- Flight programs for similar target heights and velocities tend to be similar.
I solved the problem in Python and then re-coded the solution in Basic. I tested the Basic version with several likely height and velocity combinations, using Rodion's Basic simulator. When I was satisfied that everything was working as expected, I submitted the solution only to find that it had caused an execution error. I then set about the process of making minor changes to the code and re-submitting until I no longer had an execution error. In that way I was able to identify the problem. My solution made use of the global height variable hei but it seems that this is no longer available in the checker version of the simulation. Given that the height is one of the three target quantities it seems reasonable to expect to be able to access it. However, once the problem is identified it is very easily circumvented by calculating the height. This is very easy to do since the global variables x, y and re are all available from the checker program. Having made this change everything worked as expected through the checker.
Once again, can I express my thanks for a very entertaining problem. It is definitely worth trying.
Oh, thank you, Clive, that is definitely my mistake!
Variables are renamed in the "checker simulator" (to prevent unintentional collision or hacking) so they then need
to be copied to normal names anew before each call to pilot subroutine. I just missed that hei needs to be
included, sorry for inconvenience - hopefully fixed now!