ConwayLife.com

I saw the current destroy.exe has limitation of 248x248 grid. Can you change/remove/make possible to adjust/make additional version where the limitation is higher or non existent?

simsim314 wrote:I saw the current destroy.exe has limitation of 248x248 grid. Can you change/remove/make possible to adjust/make additional version where the limitation is higher or non existent?

The reason for the limit is that intermediate results from one round are stored down into a byte stream, using one byte for each coordinate value. I could make a fix for that, but it would be helpful to know what is likely to be an acceptable limit, 504×504, 1016×1016, or more than that?

simeks wrote:I could make a fix for that, but it would be helpful to know what is likely to be an acceptable limit, 504×504, 1016×1016, or more than that?

Well for now I managed to fit exactly at the 248 boundary, but I think some of the posts for Orthogonid etc. could be much larger. I think the largest construction I can think of (say quadratic replicator) is even larger than 1016x1016.

simeks wrote:The reason for the limit is that intermediate results from one round are stored down into a byte stream, using one byte for each coordinate value

If you need this not as a hash - maybe it's better to copy the whole result, calculating the bounding box at the beginning of the run. I'm afraid making assumptions like this is hurting the app, while the major performance issue is probably the iterator anyway.

If you only need this as a hash for "been there done that" you could easily create some hash function even of size 64 bits. You can take the bounding box divide into 64 bit streams, and then make some not trivial hash function. For example (taken from LifeAPI):

for(int i = state->min; i <= state->max; i++)
{
result += CirculateRight(state->state, i);
result += CirculateLeft(state->state, (i + 7) % 47);
}

248-by-248 has always been fine for me (and the way that GoLGrid works, I think that increasing the grid area also increases the time it takes to compute a generation proportionally). For destroying larger mechanisms, it's more time-efficient to break it into pieces, run destroy256 on each piece in parallel, and add a few extra still-lifes to trigger the destruction of each piece from a single input glider.

simsim314 wrote:If you only need this as a hash for "been there done that" you could easily create some hash function even of size 64 bits. You can take the bounding box divide into 64 bit streams, and then make some not trivial hash function.

The byte stream is not used as a hash. GoLGrid already has a nice vectorizable hash function that I've used in most projects so far. It's based on the public domain MurmurHash by Austin Appleby, but instead of multiplying the current hash with a constant for each word (which prevents vectorization) each word in the key is xor-ed with a random word which is specific for the position of that key word in the grid.

simsim314 wrote:For example (taken from LifeAPI):

for(int i = state->min; i <= state->max; i++)
{
result += CirculateRight(state->state, i);
result += CirculateLeft(state->state, (i + 7) % 47);
}

The problem with such a simple hash function is that it's easy to find different patterns that hash to the same value, for example these two do (note that the position of the block differ):

calcyman wrote:248-by-248 has always been fine for me (and the way that GoLGrid works, I think that increasing the grid area also increases the time it takes to compute a generation proportionally). For destroying larger mechanisms, it's more time-efficient to break it into pieces, run destroy256 on each piece in parallel, and add a few extra still-lifes to trigger the destruction of each piece from a single input glider.

I pretty much agree, and I think the program will have trouble producing useful results for larger patterns anyway. Still it would be an easy fix to increase the limit a bit, and it will not affect performance much, because the GoLGrid datatype keeps track of the bounding box of the pattern it contains at all times, and will only evolve those parts.

simeks wrote: July 2nd, 2016, 8:41 pm

I have to look at this topic (I have not looked at the code yet).
I would rather think about glider(s) invoked destructions than the *WSS(s) destructions, as it is much easier to got a glider.
As I understand from the comments the code is looking for the objects (from a limited set) to be added (to limited regions)
to affect the ongoing reaction, such that the reaction stabilises after each added object and the evaluation function somehow evaluates the remaining objects (to be destroyed).

To use it for big patterns (ECCA in my case) you need to split the pattern to smaller regions and compute SoD for each region separately and then create gliders to reach each of the regions in the predetermined way. It seems to me it could be advantagous to allow escaping gliders from the region (probably limited some way), so the regions could serve as splitters/reflectors as well.
Destroying an escaping glider could be easier then adding additional splitters. Reflecting the escaping gliders the required way to other regions is probably the cheapest solution... (especially when the regions are far apart).

OK, no I am reading the code. I will write my toughts (cs teacher habbit) ... mid_x mid_y ... doubles just to allow halves? Maintain twice the value. length_sq ... maintan four times the value.

You compute complete "geometrical graph" probbably just to compute the minimum spannng tree.
If you want to use it for bigger patterns, consider to filter some of the edges whose cannot be part of the MST. Slsparse/pslmake could be an inspiration. (Filter does not mean consder the edge and reject it, but rather not consider it at all).
You use Kruskal algorithm to find the minimum spanning tree. Using disjoint find union technique, rather to renaming an entire component would be better (for bigger graphs). Anyways if you use it on complete graph you will still be on quadratic complexity (times log for sorting).

Oh MAX_CENSUS_OBJECTS = 512, so the complexity of the MST computation could be already important.

I like the actual cost of the edge is computed only for minmum spaning tree egdes. (I am not sure how to write the expression most efficiently ... there is a Newton interpolation in each sqrt and one would probably suffice for the entire function ... but this would not be important).
... continue reading
It tests p2 stability? So should be changed for p8 based patterns? It would be nice to know the pre destruction pattern period and check corresponding stability.

I do not understand why you use different global positions (for patterns) for each function, when the functions newer call one other. But OK let it be a style. But would adding a pattern to a function cause global renumbering, I do not think the style is good for code maintainance.

do not like "s32 stable_gen = gens_until_stable (in_setup); run_for_gens (in_setup, stable_gen);"
You can copy the final pattern from gens_until_stable rather to running the simulation twice (mod 3 calculation required to find the global pointer ... if not fixed for the purpose).

(Hmm, looking at meaning ... implementation of bleed ... so for the golgrid ... and I am confused what the pop_?_on, pop_?_off represent ... set_empty_population_rect ... I am not fun of an overcommented code, but there some hint would help. Oh its the estimate of the minimal/maximal coordinate of a living cell (and the pattern is expected to be "around the region center"). It probably only expands, but does not shrink... hmm except the tighten_pop_*... oh OK, corresponding tightening is called whenever a somehow extreme cell dies.)

OK, back to the reading destroy.c. I like the forbidden_area, must_touch_area concept. But I would try to generate objects filtered by the must_touch _area (not thinking about other objects at all) rather to have a global object list ready what would be filtered.
OK make_pos_objects called with must_touch_area could be much more efficient then trying all possible postions. ... or with all shifts by object cells ... probably already fitered by forbidden_area.

Is it DFS on relevant inserted objects returning first found solution? I must read it wrongly ... the MST evaluation must be used somehow.
Oh OK, the run_setup inserts promissing sequences to the beam ...

OK I got the idea. The most important change request would be parametrized period (allowing at least 1,2, and 8 ) and incorporation of modfied stabilty test alowing an outgoing glider ... not crossing the forbidden area. I would probably incorporated the pslmake expected costs of added objects to the evaluation as well. It would be nice to prepend the search for the starting glider line/timing to start the destruction effcently.
After some optimization it would be nice to automate larger pattern splitting to parts where chain reaction is more promissing then long jumps by reflected emitted glider. ... may be automated from the edge lengths of the minimum spanning tree of the initial pattern.

I have created unknown glider activated seed of destroyal.
https://github.com/Hippo-69/CGoL_gSoD.
It has to be tested ... it is based on simeks work and mainly on calcymans pslmake (parallel beam implementation).

The goal of the program is to compute for lifehistory patterns of parts of circuit a one time 2 glider splitter / glider turner / glider seed of destroyal.
The extended otsplitters/ turners/ sod's should be manualy connected by simple otsplitters / turners to create seed of destroyal of the entire circuit.

(It probably could be later (after a lot of experiments) automated to compute mst of the entire circuit and split the pattern to parts on mst tree edges longer than a given treshold (where it becomes more effective to send gliders than extending reaction by adding catalysts) ... and possibly automatied insertion of simple otsplitters / turners as well).

I have not experimented with using other then euklid lengths of edges. Progress evaluation uses only mst length, cost evaluation uses scaled current costs of the added objects.

Hmm, it seems to me deciding early generation as stable generation - 256 would be a bottleneck for bigger patterns, as the tail or the reaction is often far away from the remainder of the pattern so we actually want to continue reaction near the remainder of the pattern rather near the place where nothing remains.

So computing "remainder neighbourhood stable generation" could help.

Here is an example, where computation of early is definitely bad: It's perfect that the faraway trash is removed, but it takes so long tht continuation near far trash liquidation is not what we want.
The remaing portion of the pattern stabilised at generation 1567, while the faraway trash at generation 1908. Early should be 1311 rather to 1652.
Or the search should be modified to try different early generations.

There was a bug ... incorrect use of hashing (rather dependent on the thread then on the pattern), the git https://github.com/Hippo-69/CGoL_gSoD updated (with few other unimportant changes).