[martincmartin]

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.

[schiffern]

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.

[martincmartin]

Yeah, I think we're agreeing. :)

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.

[schiffern]

  >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!

[necovek]

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).

[schiffern]

  >switch to 199.999... lbs/s for all the 200 lbs/s burns, not just the last one

That's not it. See here: https://news.ycombinator.com/item?id=40685081

[konstantinua00]

speaking of speaking past each other

> and then replace one of the subsequent 200 lbs/second inputs with 199.99999999 lbs/second

> replace one

indeed not the last one, but no, not "all"