Rule Tables + Weighted Life + Larger than Life
Rule Tables + Weighted Life + Larger than Life
There should be a rule family that combines all 3 of these families together. I have created interesting rules in Rule Tables and Weighted Life but Larger than Life patterns tend to die to quickly. These combined rule families should allow a much larger diversity of patterns compared to what one rule can do by itself.
Re: Rule Tables + Weighted Life + Larger than Life
I am guessing that Larger than Life patterns tend to die more quickly because there are so many cells in the neighborhood. There are 9 cells involved with Life while adding the next row brings it up to 25 cells. More interesting to me would be to have larger diameter neighborhoods, but only select cells in that neighborhood would have any effect on B & S.
Re: Rule Tables + Weighted Life + Larger than Life
Weighted rules are possible (albeit very difficult) to make in a rule table, so I'm sure one could make a python script to simplify the process. Higher level Moore/Von Neumann neighborhoods are yet to be implemented in Golly, unfortunately.
Re: Rule Tables + Weighted Life + Larger than Life
He/she is using MCell, not Golly.
Weighted Life is trivial to implement in a Golly rule table (tree works even better), but I don't think that MCell rules offer the same flexibility.
If you want a more general rule than those offered by MCell and Golly, then I suggest writing your own program.
Weighted Life is trivial to implement in a Golly rule table (tree works even better), but I don't think that MCell rules offer the same flexibility.
If you want a more general rule than those offered by MCell and Golly, then I suggest writing your own program.
What do you do with ill crystallographers? Take them to the mono-clinic!
Re: Rule Tables + Weighted Life + Larger than Life
My understanding at this point is that the change to larger neighborhoods in golly would be easy at the source level. I do not have any specifics, only a hint from the writings of one of the authors of golly.
I'm pretty busy for a few weeks, but I think I will look into it some more.
I'm pretty busy for a few weeks, but I think I will look into it some more.
Re: Rule Tables + Weighted Life + Larger than Life
It's actually rather difficult to do. Assuming that we're using the HashLife algorithm, then the 'leaf' nodes of the quadtree would need to be larger than 2*2. With a radius-k neighbourhood, they would need to be 2k*2k.My understanding at this point is that the change to larger neighborhoods in golly would be easy at the source level.
That way, for a radius-8 neighbourhood, the leaf nodes must be 16*16. Then, a 32*32 block of four leaves determines the central 16*16 block in the next generation. A 64*64 block determines the central 32*32 block in two generations; a 4k*2^n block determines the 2k*2^n block in 2^n generations (here k = .
Simple in principle, but it would take a lot of re-wiring before Golly can handle this.
What do you do with ill crystallographers? Take them to the mono-clinic!
- iconmaster
- Posts: 42
- Joined: July 2nd, 2009, 7:22 pm
Re: Rule Tables + Weighted Life + Larger than Life
I can't believe with Weighed Life that Golly hasn't added a seperate algorithm for it yet.
It would be much easyier then making a rule table.
It would be much easyier then making a rule table.
Re: Rule Tables + Weighted Life + Larger than Life
I'm not going to pretend to be an expert in programming when I'm not, but it seems like adding another algorithm would be a lot more work than writing a rule table.
Re: Rule Tables + Weighted Life + Larger than Life
Well, writing a rule table is not easy for this, and it can get pretty bloated with all the scripts and in-between neighbors to simulate it, so I think writing an algorithm would be better.
- iconmaster
- Posts: 42
- Joined: July 2nd, 2009, 7:22 pm
Re: Rule Tables + Weighted Life + Larger than Life
I mean, algorithms are simply easier.
Instead of having to tweak a file for a new rule, you just punch in a few numbers in a textbar!
Instead of having to tweak a file for a new rule, you just punch in a few numbers in a textbar!
-
- Posts: 111
- Joined: May 19th, 2010, 7:35 am
- Location: Cambridge, UK
Re: Rule Tables + Weighted Life + Larger than Life
Iconmaster wrote:
You seem to be overlooking one simple detail. Somebody has to write some code for Golly to make this happen before you get your text dialog. I've implemented Weighted Life rules in my own home-brew programs to only a limited extent and realise that this really isn't straightforward and is going to be tricky to implement in a program like Golly in a way that doesn't impact on performance. If you have a way of implementing Weighted Life in Golly which doesn't affect its performance then please submit a patch to the dev team. I suspect that many people (myself definitely included) would welcome this contribution.
I'm sorry if I come across as blunt and curmudgeonly, but I'm more impressed by people who make things happen than by people who talk about making things happen. The Golly team have done, and are doing, a great job. If there is a rule-set or neighbourhood out there that isn't catered for it probably means that it isn't simple to integrate into the code.
Easier for whom?I mean, algorithms are simply easier.
Instead of having to tweak a file for a new rule, you just punch in a few numbers in a textbar!
You seem to be overlooking one simple detail. Somebody has to write some code for Golly to make this happen before you get your text dialog. I've implemented Weighted Life rules in my own home-brew programs to only a limited extent and realise that this really isn't straightforward and is going to be tricky to implement in a program like Golly in a way that doesn't impact on performance. If you have a way of implementing Weighted Life in Golly which doesn't affect its performance then please submit a patch to the dev team. I suspect that many people (myself definitely included) would welcome this contribution.
I'm sorry if I come across as blunt and curmudgeonly, but I'm more impressed by people who make things happen than by people who talk about making things happen. The Golly team have done, and are doing, a great job. If there is a rule-set or neighbourhood out there that isn't catered for it probably means that it isn't simple to integrate into the code.
Re: Rule Tables + Weighted Life + Larger than Life
When I get better at python, I'll try making a script to automate the rule table creation. However, school just started, so I may not find time.
Re: Rule Tables + Weighted Life + Larger than Life
Use the "Rule Table to Tree" script. There are only 512 possible neighbourhoods (for 2-state, which is all MCell supports), which would result in a relatively small rule tree.If you have a way of implementing Weighted Life in Golly which doesn't affect its performance
Implementing a new algorithm is much more difficult than creating a rule table/tree. The reason that rule tables run so fast is because Golly uses a multi-state HashLife programmed by Tom Rokicki. And even describing the algorithm, never mind actually programming it, is lengthly:I mean, algorithms are simply easier. Instead of having to tweak a file for a new rule, you just punch in a few numbers in a textbar!
In HashLife, the entire universe is stored in a compressed (hashed) quadtree. For a 10^12 * 10^12 pattern, this quadtree is as many as 40 levels deep. The 'leaf' nodes contain four numbers between 0 and 255; the other nodes contain four numbers (pointers to addresses in memory) between 0 and 2^32-1 (resp. 2^64-1) in 32-bit (resp. 64-bit) Golly.
You may have used a Life simulator where cells are grouped into 2*2 boxes, and four of those determine the central 2*2 box in the next generation. This is what occurs near the leaves of the quadtree. At the 'trunk' of the quadtree, this is scaled up by many orders of magnitude. Another technicality is that the central 2^n*2^n box is offset by 2^n-1 cells with respect to its parent 2^n*2^n boxes, so the grid alternates, similar to the Margolus neighbourhood.
But that isn't the entirity of HashLife. If that were so, it would rapidly engulf all available memory. HashLife has to combine identical nodes into a single node, in order to compress huge patterns such as wedge-grow+2^60 into the minuscule amount of RAM on a personal computer. That requires some way of being able to compare vast branches of the quadtree, which can represent squares of cells larger than the known universe. This usually involves a sophisticated hash function, which has to be ingeniously designed to minimise the possibility of hash collision. And even that isn't enough -- HashLife requires a dedicated garbage collector, to prune unused branches of the quadtree.
Easier than writing a rule table/tree?
What do you do with ill crystallographers? Take them to the mono-clinic!
Re: Rule Tables + Weighted Life + Larger than Life
Do rule tables/trees run in Hashlife?calcyman wrote:Implementing a new algorithm is much more difficult than creating a rule table/tree. The reason that rule tables run so fast is because Golly uses a multi-state HashLife programmed by Tom Rokicki. And even describing the algorithm, never mind actually programming it, is lengthly:I mean, algorithms are simply easier. Instead of having to tweak a file for a new rule, you just punch in a few numbers in a textbar!
In HashLife, the entire universe is stored in a compressed (hashed) quadtree. For a 10^12 * 10^12 pattern, this quadtree is as many as 40 levels deep. The 'leaf' nodes contain four numbers between 0 and 255; the other nodes contain four numbers (pointers to addresses in memory) between 0 and 2^32-1 (resp. 2^64-1) in 32-bit (resp. 64-bit) Golly.
You may have used a Life simulator where cells are grouped into 2*2 boxes, and four of those determine the central 2*2 box in the next generation. This is what occurs near the leaves of the quadtree. At the 'trunk' of the quadtree, this is scaled up by many orders of magnitude. Another technicality is that the central 2^n*2^n box is offset by 2^n-1 cells with respect to its parent 2^n*2^n boxes, so the grid alternates, similar to the Margolus neighbourhood.
But that isn't the entirity of HashLife. If that were so, it would rapidly engulf all available memory. HashLife has to combine identical nodes into a single node, in order to compress huge patterns such as wedge-grow+2^60 into the minuscule amount of RAM on a personal computer. That requires some way of being able to compare vast branches of the quadtree, which can represent squares of cells larger than the known universe. This usually involves a sophisticated hash function, which has to be ingeniously designed to minimise the possibility of hash collision. And even that isn't enough -- HashLife requires a dedicated garbage collector, to prune unused branches of the quadtree.
Easier than writing a rule table/tree?
Re: Rule Tables + Weighted Life + Larger than Life
No, I don't think so.Do rule tables/trees run in Hashlife?
Re: Rule Tables + Weighted Life + Larger than Life
Do rule tables/trees run in Hashlife?
They certainly use HashLife. Try running this in Hyperspeed mode:
Code: Select all
x = 12, y = 7, rule = Codd
.5B$BAF.2AB$BA3BAB$BAB.BAB$BA3BA5B$B2A.G6AB$.10B!
What do you do with ill crystallographers? Take them to the mono-clinic!
Re: Rule Tables + Weighted Life + Larger than Life
Just to clear up any possible confusion, the "HashLife" algorithm included in Golly is a highly optimized implementation for two-state CA. The RuleTable and RuleTree algorithms use a more generalized version of HashLife that supports multi-state CA (up to 256 states). This is also true for the JvN and Generations algos. In fact, QuickLife is currently the only algo that doesn't use a hashing scheme.Do rule tables/trees run in Hashlife?
Tom has done an excellent job of making it relatively easy to write a new algorithm based on the multi-state hashlife (not as easy as writing a new .table or .tree rule, but certainly much easier than writing a completely new algo from scratch). I'd urge people interested in writing a new algo to download Golly's source code and have a look at the code that implements the Generations algo. This is in generationsalgo.h and generationsalgo.cpp. The .h file is almost trivial, and even the .cpp file has less than 200 lines of code. Essentially you need to write a setrule() routine that decides which rule strings your algo will support, and a slowcalc() routine that returns the new state of a cell based on its neighboring cells.