Puzzles and "Project von Neumann"

For scripts to aid with computation or simulation in cellular automata.
User avatar
simsim314
Posts: 1702
Joined: February 10th, 2014, 1:27 pm

Re: Puzzles and "Project von Neumann"

Post by simsim314 » June 10th, 2019, 1:16 am

pcallahan wrote: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
Posts: 319
Joined: April 26th, 2013, 1:04 pm

Re: Puzzles and "Project von Neumann"

Post by pcallahan » June 10th, 2019, 2:36 am

simsim314 wrote: 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.

User avatar
simsim314
Posts: 1702
Joined: February 10th, 2014, 1:27 pm

Re: Puzzles and "Project von Neumann"

Post by simsim314 » June 10th, 2019, 5:04 am

pcallahan wrote: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?).

User avatar
dvgrn
Moderator
Posts: 5874
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Puzzles and "Project von Neumann"

Post by dvgrn » June 10th, 2019, 7:49 am

pcallahan wrote:
dvgrn wrote: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.
pcallahan wrote: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 --
simsim314 wrote:... 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.

User avatar
testitemqlstudop
Posts: 1187
Joined: July 21st, 2016, 11:45 am
Location: in catagolue
Contact:

Re: Puzzles and "Project von Neumann"

Post by testitemqlstudop » September 17th, 2019, 1:12 am

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.

User avatar
BlinkerSpawn
Posts: 1905
Joined: November 8th, 2014, 8:48 pm
Location: Getting a snacker from R-Bee's

Re: Puzzles and "Project von Neumann"

Post by BlinkerSpawn » September 17th, 2019, 3:26 pm

Would auto-generated history be of any use, a la Seeds of Destruction?
testitemqlstudop wrote: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.
LifeWiki: Like Wikipedia but with more spaceships. [citation needed]

Image

Post Reply