Puzzles and "Project von Neumann"

[simsim314]

I think we want the puzzle definition itself to be stripped bare of software-specific formats as much as possible.

You're welcome to post in any format you see fit. I think there is nothing mysterious in LifeHistory, it's basically Life with tracing history that's all. You could define history format for any rule - many times when I want to explore a new rule I suffer there is no equivalent history rule - it's just visually very useful. Also for now I guess we can stick to golly - what kind of software tools are you using? I think somehow golly became post facto the default tool of the community. Anyway you're welcome to post your alternative.

[pcallahan]

You're welcome to post in any format you see fit. I think there is nothing mysterious in LifeHistory, it's basically Life with tracing history that's all.

Right. And I'm not trying to stop anyone else from using their preferred format. Dave Greene was soliciting preferences and I expressed mine. Possibly LifeHistory serialized format is much easier to understand than I think it is. RLE for a single generation is simple enough that if you had to, you could readily translate a pattern of up to a few dozen cells on graph paper by hand. But maybe I just know the format.

As I said, I have used LifeHistory within Golly, but whenever I find that I've accidentally serialized the pattern in LifeHistory format, my inclination is to switch it back to RLE because LifeHistory text format just looks too complicated to me. This may not be a "rational" preference. It's entirely possible that I'm coming up with a post hoc justification for tradition. Either way, I definitely prefer to see patterns in one-generation RLE.

[simsim314]

Dave Greene was soliciting preferences and I expressed mine. I definitely prefer to see patterns in one-generation RLE.

I would agree that for beginner puzzle solvers it could be a bit overwhelming, at least some sort of "toggle" between the usual view and LifeHistory view might help and be useful or more intuitive (as you said). But for puzzle designers, I would claim LifeHistory is just an option to pass more information. It might be tricky to understand what each color means in dvgrn's puzzle design (it's a bit confusing indeed), obviously we will need to provide a strict puzzle designer protocol, but in my opinion the colors are giving too much information (for example input and output of a component could simply be of different color - how would you provide input output with usual rle format?).

[dvgrn]

Quick straw poll: how many people out there still can't stand LifeHistory

I will go with "not a huge fan." It is a powerful tool, but when I've used it in Golly, I get frustrated when my first attempts to save a pattern do not produce classic RLE.

I suspect that's a fairly common feeling among Life pattern engineers who aren't me. This probably partly explains why so few people have tried the sample puzzles so far.

On the other hand, whenever I personally have to solve any assembly puzzle along these lines, if it's in plain RLE I immediately convert it to LifeHistory (Alt+H in Golly 3.x), and establish the input and output tracks for gliders, the construction envelope of any oscillators, etc. It seems enormously useful to have all that information instantly visible, without having to add and maintain extra dots to mark key paths and edges.

I also can't integrate it with legacy tools (often of my own making).

Last time a LifeHistory problem came up, if my rather vague memory is correct, you might have been still running Golly 2.8 or so then. If so, have you upgraded yet? There are downloadable Python scripts available that get rid of LifeHistory for you for Golly 2.x, but the Lua scripts in Golly 3.x are mapped for you -- Alt+J to get back to plain-vanilla Life when a construction is done.

This isn't exactly the kind of view toggle suggested by simsim314 --

... at least some sort of "toggle" between the usual view and LifeHistory view might help and be useful or more intuitive.

Alt+J actually removes all the extra states, rather than just temporarily hiding them. I've never had any use for a temporary two-state view, except for Alt+J followed by Ctrl+Z, which really works perfectly well. The Undo system is a huge part of my standard editing workflow.

[testitemqlstudop]

Here's an idea for the server-side implementation.

Each puzzle will be a list of (cell list 1, cell list 2 @ t).

Basically, each line means "when each of the cells in cell list 1 are toggled, there must be some generation 0 < i ≤ t where all cells in cell list 2 are toggled".

Cell (x, y) is toggled at generation t if and only if cell (x, y) at generation 0 and the cell (x, y) at generation t is at a different state.

[BlinkerSpawn]

Would auto-generated history be of any use, a la Seeds of Destruction?

Here's an idea for the server-side implementation.

Each puzzle will be a list of (cell list 1, cell list 2 @ t).

Basically, each line means "when each of the cells in cell list 1 are toggled, there must be some generation 0 < i ≤ t where all cells in cell list 2 are toggled".

Cell (x, y) is toggled at generation t if and only if cell (x, y) at generation 0 and the cell (x, y) at generation t is at a different state.

You would need to tighten the condition: when each of the cells in cell list 1 are toggled, there must be some generation where only all cells in cell list 2 are toggled.
Ignoring the rest leads to dirty solutions.
Of course, in some circumstances dirty solutions might be acceptable, so perhaps it could be an optional parameter that would allow "scoring" solutions by cleanliness.