I'd been explaining sonic booms and high explosives to my kids, and thought that showing them a simulation of wavefront propagation might be a fun way to illustrate how they worked. I figured I could do that with a simple cellular automaton, so I threw something together in a few hours, but my sim didn't have anything like the right behavior. So there I was with a general cellular automaton framework, thinking about wave propagation, and wondering what else I could do with it. Inspiration struck, and I just had to try doing this.
Thanks! Most of my fun projects tend to be of the fiddle-for-years type, so it was great to find something small enough to polish off in a few months. And of course I had to resist the urge to keep adding to it, but the constraints helped...there are only so many bits to use.
I wish I could give you an award for this. I've been working on developing cellular automata for solving sudoku, but you're lightyears beyond what I've so far been able to do.
No, I haven't pushed any of my code yet. First steps have just been getting automata working (which I'm struggling with because I wanted to do this in python) and generating solved sudoku (finished that).
The second step is to build an array for all the 'cells' in a sudoku board. Really, all the information for every 'cell' is 3 matrices of 8 other cells (row cells, column cells, major cells). Then, another `TODO`, enumerating all of the 'conditionals' for the automata? If you want to DM me, I'd love to pick your brain on this. How to define the conditionals for the rules, etc.
Then the plan was to just push DL compute at it: generate a set of conditionals; sets of random sudoku boards; allow the algorithm to run GoL-Sudoku flavor; score them based on their performance; feed this back as the response in the DL model; rinse; wash hands; compute.
Ah, I see. I'm afraid I don't have any advice on how to define the conditionals because I don't know a distributed algorithm for solving sudoku. Presumably you'll need some sort of guarantee that the sudoku has a unique solution, otherwise things could get very messy and/or slow. And you won't be able to fit the board state in 32 bits, even if you can somehow take out rotations and such, so you can't have the full current state available to a given cell.
I suspect just throwing DL at it without giving it more to go on won't find a solution in a reasonable amount of time.
When I say conditionals, I mean the particular rules for the automata. So like GoL the data going into a state change is a count of the neighborhood in the area of the cell. There are some thresholds (number of neighbors), and then based on the conditionals, the state is updated.
So one conditional is the size/ dimensionality of the neighborhood. Another, in your case, is the class of the pixels.
I meant to take some time this weekend to dig into your code and look at how you've structured your conditionals.
