muzik wrote:I think you posted a command to show the amount of soups you had contributed a year or so ago, but when I tried typing it in to the terminal it didn't work. Am I a complete idiot for typing it there and not somewhere else, or do I need certain packs/requirements/etc.?
I don't remember posting any command, but
curl http://catagolue.appspot.com/census/b3s23/C1 | grep muzik should work in both Cygwin and bash. You may need to explicitly install curl if you're using Cygwin, though.
Also, assuming you've tested it so far, how fast does apg4.0 average on B3/S23? How about B3/S?
Disappointingly, the fluff involved in manipulating hashed quadtrees reduces the performance vis-a-vis apgmera by a factor of 10 or so. The slowdown is
entirely down to annoying pointer indirection and hashing, rather than the actual GoL assembly code (which is virtually the same in 3.x and 4.0).
However, I've been able to refactor the lifelib code in such a way that the same fast leaf iterator (which can process LifeLike rules, B0 rules, and non-B0 Generations rules so far) can be invoked by either the HashLife-based algorithm or a more conventional 3.x-style algorithm (to be implemented). Then users will be free to use either the conventional or the hashed algorithm as desired: there are naturally different use-cases for each, and many projects (apgsearch included) will benefit from being able to use both of them in different circumstances. I'll ensure that I can get apgmera performance back up to the level of 3.x before committing the huge backlog of changes to the repository.
I've also had a rethink, and I can see a potential route for extending apgcodes to multistate rules so that apgsearch/Catagolue can support Generations rules. The idea is to have apgcodes of the form:
with multiple suffixes specifying each of the layers* in the pattern. So 3-state rules have 2 underscores, 4-state rules have 3 underscores, 5- and 6-state rules have 4 underscores, 7-,8-,9-,10-state rules have 5 underscores, and so on.
*lifelib technically implements multistate rules as
multilayer 2-state rules, such as LifeHistory implemented with a GoL layer, a history layer, a marked layer, and so on. The lifelib implementation of an n-state Generations rule uses 2+ceil(log2(n-2)) layers, where layer 0 is 'live', layer 1 is 'refractory', and the remaining layers implement a binary counter.
LtL for range <= 7 is the next rule family to be implemented, along with GenerationsHistory and LtLHistory. There are good reasons for stopping at range 7:
- Lifelib assumes that information travels no faster than 8c, so range-8 would be the theoretical upper limit.
- Range-7 corresponds to a 15-by-15 neighbourhood, so the neighbour count fits into a single byte. (Range-8 is a 17-by-17 neighbourhood, so you would only know the neighbour count modulo 256 rather than exactly.)
- Dean Hickerson's wonderful p552 8,12x reflectorless rotating oscillator inhabits a range-7 LtL rule:
Also, will apgsearch ever support hexagonal and Von Neumann neighbourhoods?
Potentially von Neumann neighbourhoods, yes. Hexagonal rules would be painful to implement since I've made assumptions all over the place that I can liberally rotate/reflect patterns without altering their behaviour. The usual symmetry options, such as D8_4, wouldn't make sense in a hexagonal rule; you'd need things like C3_1 and D12 instead.
My other ongoing CA-related project, hex13, suffers from the exact opposite assumption: only the hexagonal grid is supported**. This is less restrictive, though, as artificial chemistries tend to be largely insensitive to the underlying geometry (unlike ordinary cellular automata where the geometry is part of the rule). It's also platform-dependent in a very different way: whilst it doesn't care about the CPU, it requires a CUDA-compatible GPU*** in order to run.
** and, if I remember correctly, limited to an N-by-N torus where N must be divisible by 208.