I suspect that they might have switched away from the booster separation on purpose. That's probably a risky moment of the launch, and they may have wanted to avoid televising a disaster like in the Challenger launch.
Aside from that, agreed that the camera work was awful.
Oof. I had a great time cracking the top 100 of Advent of Code back in 2020. Bittersweet to know that I got in while it was still a fun challenge for humans.
This is all right, but it just kicks the intuition into the assumption that the function is convex. As far as I can tell from the paper, this turns out to be exactly the argument they use to prove that (1/2, 1/2) is the optimal guess. But the majority of that proof is dedicated to showing that the function is indeed convex.
Sure, I think it makes intuitive sense to me that you should play riskier when you're behind. The surprising part to me is that when you're ahead, even if you know that your opponent will play "sub-optimally", that doesn't change your own optimal move.
I know that it minimizes the expected number of moves. But, the goal is to maximize the probability that you win in fewer moves than your opponent, not minimize the expected number of moves. Given that your opponent is playing some riskier strategy, it's not intuitively obvious to me that your optimal moves for those two objectives are the same.
I find it somewhat surprising that the optimal play when you're ahead is still just binary search. Is there an intuitive reason why it's not productive to make riskier guesses? Why not use my lead to have some chance of sealing my victory immediately, while still maintaining my lead if I'm wrong?
Wow. You reminded me of a computer engineering class years ago where we wrote assemblers and emulators for a simple architecture. I tested mine by writing a solution for one of the first Project Euler questions!
I wonder if it would show up on the heart rate (or heart rate variability) tracking from an Apple Watch or similar. My Garmin picks up stressful events all the time.
Incredible work! I recently gave a talk about TASing to an audience of CS grad students, and of course I had to mention your SMB3 runs. Your videos are phenomenal at making this stuff accessible outside of hardcore gaming circles.
The entire TAS file takes about 16 MB, far more than the 4 KB of RAM on the NES. During the audio + video playback, the TAS is streaming via the controller by making inputs roughly 500 times per frame (15 kHz).
I'm not sure about Gurobi or how the author used it in this case. But in general, yes: these combinatorial solvers construct proof trees showing that, no matter how you assign the variables, you can't find a better solution. In simpler cases you can literally inspect the proof tree and check how it's reached a contradiction. I imagine the proof tree from this article would be an obscenely large object, but in principle you could inspect it here too.