Well, I think it's about time we brought together every format into an agreeable, deep, and effective rule table. It will be very difficult, but I have a list of all the things we need to specify in one of these tables. I believe the best way is XML, Like this:
ssaamm wrote:Well, I think it's about time we brought together every format into an agreeable, deep, and effective rule table. It will be very difficult, but I have a list of all the things we need to specify in one of these tables. I believe the best way is XML, Like this:
What do you think?
There is absolutely no need for such a complex format. XML is not always the right way to do things. It's too bulky.
That said, we need an easier way to define complex ruletables. Maybe a RuleTree-like approach, but without having to create a RuleTree from it.
It would be nice to have one final format for all rules. Rule tables fill a niche but have shortcomings: many complex rules seem to be better expressed in high-level languages like Python, C++ and Java. (Golly supports Python rules (see make-ruletree.py) but only for rules with few enough states and neighbors that we can iterate over all input combinations.)
Before working on a new format though, be sure to check out existing ones like cellang and CDL, as listed here: http://code.google.com/p/ruletablerepos ... /TheFormat
Any new format would have to have some advantage over those.
Tim Hutton wrote:(Golly supports Python rules (see make-ruletree.py) but only for rules with few enough states and neighbors that we can iterate over all input combinations.)
Exactly! Now, if we could just run the code directly, those limitations on states and neighbours would go away. Of course, letting anyone plug their own Python code into Golly is probably not a good idea.
Well, would there be a better way to incorporate custom neighborhoods based by state into the current rule table format?
Also, would it be possible to have the .colors file be part of the rule table?
Tim Hutton wrote:(Golly supports Python rules (see make-ruletree.py) but only for rules with few enough states and neighbors that we can iterate over all input combinations.)
Exactly! Now, if we could just run the code directly, those limitations on states and neighbours would go away. Of course, letting anyone plug their own Python code into Golly is probably not a good idea.
Err, no. I don't believe that will help at all. No matter how the code is run it still has to be iterated over, running native code would only make it faster by some constant factor which would not be nearly enough.
Essentially, what we need is a cut-down scripting language which Golly can analytically compile into a ruletree.
This is why signature character limits are pointless.