Research Notes & Organization Practices

[MXMLLN]

I'm getting deeper into my cellular automata research and could use some advice on how to organize my research. Anyone have any best practices?

Generally I start each project with a Notes document and a separate spreadsheet for table data. However, Life requires saving simulations GIFs, their respective specifications and attributions to their inventors (if relevant), as well as other categorization data. I could really use a spreadsheet template. Suggestions on how to organize a document folder structure, including file naming conventions, would also really help.

How does everyone manage all the information?

[Chris857]

My focus has largely been on glider syntheses of still lifes from soup and oscillators. I have a folder on my computer of (most) every synth I've done in separate RLE files, so I can go back later if I think up improvements to put in them. Those are also the scratch space I use to try out different synth options. I also have a very large RLE I'm building up and organizing with a whole bunch of different syntheses of different clearances that I'll eventually publish when it has some better semblance of organization (but it's getting there)

I keep notes of things I want to work on in a Google document so I can add to it and cross off items.

[hkoenig]

Rather than the massive "stamp collection"* file, you might want to consider setting up a database or spreadsheet where each pattern has it's own line or entry, along with metadata like target object, result object, number of gliders needed, notes, etc. Something sortable and searchable. Use apgcode (I only use the bitpattern portion, and ignore the prefix) instead of RLE for simple objects, as it can be used as an index or key. Names should be optional.

If you do have custom formatting or identification schemes, take the time to write simple routines to convert/translate to/from something common like apgcode or simple, two-state RLE, especially if you aren't saving that info in the record.

Something I was told long time ago-- "a filesystem is a poor substitute for a real database." I think it's still true. But if you must, don't be afraid to nest directories and keep file names simple.

---

* Stamp collections can be pretty, but a major problem with them is when you start making changes. It's difficult to impossible to tell what changed or to compare files. Meta-data and descriptions can sometimes take up more space than the patterns, or are relegated to separate files that need to be kept in sync. And having patterns overlap when run can cause problems too.

[confocaloid]

I think most of my CA-related files are in the "eternal sandbox" state. Surely it could be better organized than it is.

For B3/S23 Conway's game of Life, there are some directories for specific "projects" (e.g. "syringebasedp256gun" for an old attempt to make a reasonably small period-256 glider gun that uses syringe instead of relying on the R64 conduit), as well as some directories for collections of patterns of some type (e.g. "slfactories" for components that can be used to convert a well-explored active object into a still life).

For other CA evolution rules, there is a separate directory for each rule (named either by the rulestring or by the widely-accepted alias). There are also some "project-specific" directories, and some directories specific to a small set of rules (a rulespace).

One alternative to big stamp collections (which become unreasonable beyond some size, and/or when there is a need for regular updates) is a plain text file containing RLEs with comments:

Code: Select all

#C block
x = 2, y = 2, rule = B3/S23
2o$2o!

#C beehive
x = 4, y = 3, rule = B3/S23
b2o$o2bo$b2o!

...

It is simple, lightweight, flexible (there are no required fields / rigid structure to be followed), and this solution does not rely on any software technology that can become outdated/unavailable/inconvenient to use. I can make a diff between two text files to see changes between versions. I can perform text search in a text editor, and a Python script can be used for more complicated processing.

[hkoenig]

One alternative to big stamp collections (which become unreasonable beyond some size, and/or when there is a need for regular updates) is a plain text file containing RLEs with comments

Yes. That's another good way to do it. I use it for temporary files or patterns needing more work.

this solution does not rely on any software technology that can become outdated/unavailable/inconvenient to use.

I've made that mistake, and lost data that way. Stick to data formats that will be around for awhile. Text, SVG, PNG, PDF and the like. (Jpeg is not good for CA images.) I've dumped my SQLite files so that it can be recreated by any SQL compatible database, just in case.

(Has anyone written a utility that could generate a stamp collection from such a file? Seems like it should be moderately easy, maybe with a few obvious customization options like "number of rows/columns", spacing. A way for someone who wants to contribute to do something.

Similarly, writing a interface/front-end for common tools would be another useful endeavor. A while back I created an Xcode project which wrapped apgnano, allowing it to be run as a Mac app. Basically the app built the command-line and passed that to the main() func, which, after fixing some multi-tasking issues, did the calculations. An enhancement would've been a way to display results graphically. Never did use it because I don't and won't have the account with Evil, Inc. needed to do submissions.)

[dvgrn]

(Has anyone written a utility that could generate a stamp collection from such a file? Seems like it should be moderately easy, maybe with a few obvious customization options like "number of rows/columns", spacing. A way for someone who wants to contribute to do something.)

Pretty close, yes! There's a Python script that currently builds an oscillator stamp collection from this oscillators.txt file -- which is in exactly the format that confocaloid describes.

As seems to be usual with these kinds of projects, the Python script is pretty close to unreadable and rather difficult to maintain, since features and bug fixes just got piled into it until it worked. But it does work! It builds the oscillator stamp collection that is currently packaged with Golly. If you use the showinviewer.lua script, you can zoom in on the oscillators and see labels for each one.

So there's definitely room for improvement, but what we have right now takes care of the use case that we have right now -- which is a lot better than nothing.

There was something similar for the Elementary Conduits Collection for a while, before it got accidentally sabotaged by a new presentation format and we ended up right back with a big flat RLE file and no metadata (except the in-pattern LifeHistory labels.)

[MXMLLN]

Thanks for all the ideas!
For now, Koenig's spreadsheet column labels will probably be sufficient for what I currently need.