I learned BASIC programming when I was 11 in 1981 (I think that’s right) at a summer computer camp on an Apple II.
I made a simplified version of lunar lander… it was ridiculously fun to make and play.
One of my cohort mates who was in the “advanced” Pascal class is still my friend to this day.
Rather than a large deviation from a suicide burn at the end of the burn, a small deviation at the beginning of the burn should be a cheaper way (w/r/t fuel burn) to "search" the buggy code for a possible soft landing solution.
Anyway, what a fun write-up! Thanks for posting it.
So it turns out, before discovering the bug, I actually wrote code to find the optimal sequence when your choices are restricted to integers. I thought, along the same lines as you, "maybe if you burn 165 or 170 or something in the first non-zero term, then you could burn less on the 14 turn and still land."
And this is how I know it's not possible, at least with integer burn rates. :) I checked all 201^9 combinations, with a few optimizations to cut down the search space.
That's different than what you said, of using floating point for the last burn. But it is in a similar spirit.
I thought it was a little odd that he mentioned "impressive for a high school senior in 1969" multiple times throughout -- honestly I would imagine that growing up in the Space Age would have had a massive influence on technically minded folks, reminds me of that movie from a while back called October Sky.
In the interview in TFA with the game's author he mentions being skilled at calculus--seems to me that if you were interested in space/rocketry/etc. and had the aptitude it makes sense that you'd try your hand at programming a lunar landing game.
[1]: https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
OP here. I see your point. But think of what's needed to create this game:
- From high school physics, you know to start with a free body diagram. There are two forces, gravity and thrust. So far, your average high school student with an A in physics should be able to do that.
- Gravity depends on the distance to the center, which of course is changing, that's the whole point of a lander. I mean, you start 120 miles up. You have to realize it doesn't change much, so can be approximated as a constant. But you've been exposed to that in physics class, so maybe you just assume it's a constant.
- How the hell does thrust work as a function of burn rate? Is the exhaust velocity higher when you burn more? In other words, considering 100 lbs/sec vs 200 lbs/sec, when you double the flow of fuel into the engine, and then you burn it, it turns into twice as much fuel in the same volume. Wouldn't it be forced out at twice the speed? Or at least a higher speed? Maybe you think of the universal gas law, PV=nRT. The volume is constant (the volume of the engine), n is doubled, R is a universal constant. So that means P or T changes, or both. Why is T, which is a function of the velocity of the molecules, constant why P is doubled? Why don't both change?
- So you talk to your Dad, who happens to be a physicist. Most high school students, even those getting an A in physics, don't have a physicist for a father who can look up the properties of rocket engines and find the Tsiolkovsky rocket equation. So a high school senior finding the rocket equation is impressive to me.
- To go from velocity to position, you need to integrate. I'm not sure your average A physics senior would think of replace the FLOG() call with a Taylor series and integrating it term by term.
- How many terms of the Taylor series do you need? Does it even converge for you? If he thought of these subtleties, that's impressive. But it's possible that young Jim didn't realize these issues and just uses 5 terms because that seemed like a lot of terms.
- So now you can simulate it in near the moon. Cool! But how do you detect when it hits the ground? You could try to solve for altitude equals zero, and see if there are zero or more solutions. But even if there are solutions, they might be in the past or the future. So instead you decide to look where the velocity is zero, since you know this happens exactly once during the turn. I think that shows some ingenuity there, although I don't know if that was 18 year old Jim's thought process.
- So you try to invert the rocket equation: given a desired delta-V, how much fuel do you need to burn to achieve it? If you try this with pencil and paper and high school math, including Calculus, you keep getting stuck. You don't have the tools to show that it's actually impossible and needs you to introduce a new function, the Lambert W.
- So maybe you give up, or maybe your physicist Dad helps you again. Using your Taylor series, you now have to solve a 5th degree polynomial. So you decide to scrap the 3rd, 4th and 5th term to get yourself a quadratic. Why is it ok to scrap these now, when it wasn't ok when computing the regular dynamics? I'm impressed that he realized he can use different levels of approximation in different circumstances, without it generating some inconsistencies or other problems.
- You somehow figure out how to use the alternate form of the quadratic equation, which means you didn't just look it up and type it in. Possibly impressive.
>It’s also possible to land gently, you just need to end your 14th turn with a low altitude and velocity, and then use low thrust in your 15th turn, landing somewhere after 150 seconds. It’s just the theoretical full-thrust-on-landing suicide burn, that takes around 148 seconds, that eludes us.
I expect the fuel-optimal soft landing strategy (ignored because it doesn't fit the exact form of a "suicide burn") would be to play 164.31426784 lbs/second at t=70 seconds, and then replace one of the subsequent 200 lbs/second inputs with 199.99999999 lbs/second.The earlier you "play" 199.99999999 the better, so just use exhaustive search and select the earliest play that still achieve a soft landing.
Even when the bug is fixed, the code is still only approximating the lowest point. Also, even when it detects that you've landed, now it needs to compute the time when you land, i.e. when the altitude is zero, not velocity. It also uses an approximation for that.
So the times will be a little off. If you're burning 200 or 199 during that last time step, you have a high acceleration so even a small amount of time turns into a large amount of velocity. Instead, if you're burning say 10 lbs/sec, then being off by say 0.08 sec won't change your velocity much.
>The rocket equation is what gives rise to the suicide burn being optimal
Nitpick, but this isn't strictly true.Even if you don't count the vehicle getting lighter as it burns fuel (which is all the rocket equation does here), a suicide burn will still be optimal.
The real reason is because a suicide burn minimizes gravity loss.
M*G/Z*K
I think you meant, the above and
M*G/(Z*K)
respectively.
f(cQbit)=> bath = decompose(cQbit)
Bath now has information about the central Qbit stored in the bath.
Any measurement of cQbit changes the state of cQbit and destroys any correlation with the bath.
Regardless of the state of cQbit: you can rebuild the cQbit with the information about cQbit stored in the bath.
f(bath)=> cQbit = compose(bath)
This effect seems trivial as I've explained it. So I assume I got something wrong.
Is it just the process of restoring from the bath into the cQbit that's complicated, or has a bunch of gotcha's? It seems like the state of the cQbit is inconsequential if you can just overwrite (:ah... the gotcha) it with the info from the bath.
If you can rebuild the cQbit from just the bath, then there's no information in cQbit, right?