I'm a layman here: so much salt to take with this.
I assume the factors that mitigate/negate the no-cloning theorem are that the bath is not a qBit, but a collection, that the state's are initially entangled. It could also be that the initial state of the cQbit is known, instead of unknown.
```
The theorem[1] also includes a converse: if two quantum states do commute, there is a method for broadcasting them: they must have a common basis of eigenstates diagonalizing them simultaneously, and the map that clones every state of this basis is a legitimate quantum operation, requiring only physical resources independent of the input state to implement—a completely positive map. A corollary is that there is a physical process capable of broadcasting every state in some set of quantum states if, and only if, every pair of states in the set commutes. This broadcasting map, which works in the commuting case, produces an overall state in which the two copies are perfectly correlated in their eigenbasis.
```
So it seems that there is some wiggle room, and specifically when you start working with collections instead of single qbits, things get weird.
But I'm a layman, and that was just a walk down wikipedia.
OP here. Yes, that's what I meant. Using the rocket equation, truncated Taylor series approximation, truncating even more to make things solvable, then iterating to improve the solution, were all things I wouldn't have expected.
OP here. Cool! I was born in 1969, less than a month before Neil Armstrong walked on the moon, and was only a few months old when this game was written. I too learned BASIC, then spent hours pouring over the book "BASIC Computer Games", before I even had a computer of my own. Fond memories, as you say.
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.
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.
The nature of the bug is that it has trouble finding when the lander has touched the surface. You need to have an altitude of less than zero for around 0.05 seconds for the game to notice that you've landed. If your thrust during that time is 200 or 199, to have an altitude < 0 for that long, then you need to have a speed greater than 1 MPH when your altitude is zero.
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.
I get what you're saying, but I don't think that contradicts the optimal strategy I outlined?
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, 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."
That's not exactly what I was thinking.
Clearly that won't work, because just by changing the least significant digit (ie adding 1e-8 lb/s) in step t=70 seconds, you "blow past" the soft landing window, in part due to the bug.
Evidently the move played at t=70 seconds is, in effect, too 'course-grained' to effectively target the (small) soft landing window. By shifting your "subtract 1e-8 lb/s" move (ie playing 199.99999999 lb/s) later and later in the burn, you effectively make it more and more fine-grained (for a minimum fuel penalty) until you can achieve that soft landing.
Thanks again. I'm not sure who's right, but it's certainly a very stimulating problem!
I think they are saying that you need to switch to 199.999... lbs/s for all the 200 lbs/s burns, not just the last one.
Just trying to clarify where you seem to be speaking past each other, though it seems that this might simply lead to a non-optimal strategy (i.e. taking more time to land than theoretically possible, however minute the difference is).
OP here. True, I oversimplified. What I meant was, there are two parts to the dynamics, the rocket equation and gravity. They add linearly, so any extra velocity that comes from gravity needs to be eliminated by increasing the delta V from the rocket equation. The gravity delta V is just acceleration of gravity times time, so you want to minimize the time. Surprisingly (to me), in the rocket equation, it doesn't matter how long it takes, or what sequence of burns you use, or whether you burn at a constant rate all the way through vs short strong bursts, etc. So to land with zero velocity using the least fuel, you just need to land in the shortest amount of time.
OP here. One interesting thing about FOCAL is that * has higher precedence than /. So in Lunar Lander, M*G/Z*K is what mathematicians and other languages would write M*G/(Z*K). I did a double take when I first saw that. :) As the Wikipedia article says, "This can cause subtle errors when converting FOCAL source code to other systems."
Also, the IF syntax is a little limiting and hard to read, although I suppose programmers would get used to it.
That's surprising from today's perspective, but when I imagine the thought process, it seems reasonable, especially for math and science purposes where multiplication and division operators usually get grouped into a series of multiplications above the division bar, and a series of multiplications below it.
Your code got munged, use backslash to escape * (otherwise it starts a span of italicised text), or use four leading blanks for code blocks (in which escaping is usually not needed):
They aren't actually floating-point: each label is a pair of numbers, the first denoting the group and the second denoting the line within that group. The groups have no semantic importance, they are only for organization.
Actually, I was mistaken. The line numbers aren't even numbers, so much as digit pairs, given how one-digit labels take the first digit.
And the "DO" command takes a group number, runs each line within the group, then returns after the end of the group. So each group can effectively act as a subroutine. (In this particular game, this can be seen in groups 6 and 9.)
OP here (of this blog post, not the original game). The naive way is what I expected too, and described as the Euler method in the post.
In terms of physical accuracy, especially when you get near the surface, the mass does change significantly if you have a high rate of fuel burn. But in terms of how challenging/fun it would be, and what strategies you use as a player, I doubt it would make much difference. In fact, there are other lunar lander simulations in the BASIC computer games book, I think one of them does use the naive approach.
If 10 seconds is too long, you could still leave that as the turn in the UI, but internally break each turn into a bunch of smaller time steps, e.g. 10 time steps of 1 second each. Actually, the existing game does that in certain places, which is why his physics simulation takes in an arbitrary time S rather than always the full 10 seconds.
I wish I new how that article got to 80k for a house in 1955.. I couldn't find a link to trust "interactive visualisation" they're citing and Google didn't help me either.
I wasn't born then, so no personal experience and everything I could find pointed more towards 5-10k, i.e. this advertisement
That can't be right, it must already be an inflation-adjusted number. My parents bought their most recent house in ~1970 for $30K, and that was a bit above the median for the area.
Yeah, SS7 was not really designed for the scenarios it now finds itself in (hell, I remember my dad talking to me about it back in the 80's). It's amazing how well it works, but that's exactly the context where one expects to find security vulnerabilities in spades.
If you can rebuild the cQbit from just the bath, then there's no information in cQbit, right?