gregdeon

Yep, this is exactly what I thought of too... If you believe negative lines of code is the goal, then they've gotten 8x _worse_!

Sub 3 is incredible, congrats!

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.

The conference organizers are very much aware of this possibility. Prompt injection for the sake of getting a positive review is explicitly banned.

Canadian checking in!

Unless you roll out of bed and instantly onto your commute, you're getting natural sunlight through all your windows for hours every morning.

Sadly, not if you're a student living in a basement in Vancouver!

Same here. If you shouldn't design for the average dimensions, what _should_ you design for?

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.

It always blows my mind how universal this experience was for people around my age. Mine was a bouncing ball...

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.

What a pioneer. RIP Byuu.

Wow, incredibly interesting to see what one of these manuals looks like! Thanks for sharing.

Yes: the reason why some data can be compressed is because many of its bits are predictable, meaning that it has low entropy per bit.

I think it is. Latency was just one of the problems he described. A physical controller sometimes adds "phantom inputs" as the joystick transitions between two inputs. Physical actuators also slow down with wear. A physical Atari-playing robot needs to learn qualitatively different strategies that are somewhat more robust to these problems. Emulators also let the bot take as much time as it needs between frames, which is much easier than playing in real time. To me, all of this makes a physical robot seem like a decent way to start engaging with problems that come up in robotics but not simulated games.

I watched the talk live. I felt that his main argument was that Atari _looks_ solved, but there's still plenty of value that could be gained by revisiting these "solved" games. For one, learning how to play games through a physical interface is a way to start engaging with the kinds of problems that make robotics hard (e.g., latency). They're also a good environment to study catastrophic forgetting: an hour of training on one game shouldn't erase a model's ability to play other games.

I think we could eventually saturate Atari, but for now it looks like it's still a good source of problems that are just out of reach of current methods.

Wonderfully written article! Thanks for sharing.