We actually need at least one emulator

[fj128]

The main thing that went wrong is that we stepped on the same rake we stepped on before ("oh having multiple people writing emulators is a waste of time, let's do less of that") so as a result we didn't have a working emulator until the end of Day 2 I think, which in an entirely unsurprising turn of events meant that the people wanting to write solvers were fucked because it's really hard and furthermore pointless and a dead end to write a solver that generates a solution without access to the "current state of the world" (i.e. we want "interactive solvers" as @manpages called them when he complained about that).

The main purpose of an emulator is to enable incremental solvers that need the current state of the world to decide what to do next. It is not running the entire trace faster than the slow reference implementation and saying if it's correct (that's actually kinda pointless). It is this thing that must explicitly provide methods for querying the current state, probably on a sub-timestep resolution even (so you can build up commands for your bots and know that the next bot can't do so and so because you've already submitted a command that prevents that, within the same timestep).

We need one emulator written in Python ASAP, then possibly reimplement it in C++ later. And it should be written explicitly for the solvers' benefit, providing an API they need.

[earthdok]

Should we merge this into issue #24? 😂

[earthdok]

Really though you've laid this out much better than I did, and I agree 100%

[Vlad-Shcherbina]

My fault that I even started the emulator in Python, instead of working exclusively on the solution DB and the solvers. Maybe somebody else would have done a better job at it if they didn't feel that the task was taken. I was not hellbent on the emulator during the contest, and still not sure what could have been done about it exactly.

I disagree with writing an emulator to understand the rules in depth (you are not arguing for it here but you did before). There are more efficient ways to understand the rules in depth, like reading them multiple times, drawing pictures, discussing the parts that are unclear.

I'm not too excited about writing an emulator as a blackbox trace verifier. pyjs_emulator was ready really early, and it's almost guaranteed to be correct right away. Anything else is luxury.

Finally, writing an emulator to provide the mysterious emulator state to the solver writers.

First, not all approaches to solvers can make use of the state (for example, orchestrate2.py does not deal with the global state step by step; for another example, solving "assembly" problems in reverse to avoid bots getting trapped). Second, I simply don't know what is the state interface supposed to look like. These two things mean that we should sit on the problem until either it's better understood, or becomes irrelevant.

---

So I challenge you to write an unimplemented interface for the emulator state useful to the solver writers (using lightning-only or full problem knowledge, your choice).

[earthdok]

for another example, solving "assembly" problems in reverse to avoid bots getting trapped

I'm confused. They assign job sites to bots dynamically based on which blocks remain at any given point in time, and then bots decide which blocks are safe to eat based on a connectedness check which is also done dynamically. Not to mention that they need to keep bots from running into each other. How is this not using state?

[Vlad-Shcherbina]

It uses the state, but it uses it backwards. The regular forward emulator wouldn't help here. And in the lightning round we didn't know that there was a considerable symmetry.

[earthdok]

Why not? You solve the reverse problem, then apply a simple transformation to your trace, replacing void with fill and fusion with fission etc.

Yes, there were no reverse problems in the lightning round but had we though of this approach we would've defined them.