Thread for basic questions

[b-engine]

I don't know why x and y parameters are necessary in a RLE, as position isn't absolute.

If I ever write something that runs CAs,

I'll make it ignore anything at front of "rule".

"x rule" format is rather more mobile friendly, but if it's just

Code: Select all

rule = B3/S23
! 

, then it could be a lot better; you can tell that it defines the rule.
#R can be somewhat harder to type since it contains #.

[confocaloid]

[...] I don't know why x and y parameters are necessary in a RLE, as position isn't absolute. [...]

One situation when "x" and "y" are useful, is when you are pasting a RLE. The bounding box of the stored pattern may well be smaller than the rectangle given by "x" and "y". Make a big random soup in Golly, switch to paste mode "And" or "Copy", copy-paste the following somewhere in the middle of the soup, and look what exactly happens:

Code: Select all

x = 20, y = 20, rule = B3/S23
7$8bo$9bo$7b3o!

Further, even if and when redundant, dimensions in the header are useful redundancy. When you see "x = 400, y = 300, ..." you can tell it's likely to be a 400-by-300 RLE.

[...] mobile friendly [...]

If the goal is to make it as short as possible for the sake of typing patterns by hands, then why not just type two lines like this?

Code: Select all

B3/S23
bo$2bo$3o!

Or even simpler, put everything into a single line:

Code: Select all

B3/S23 bo$2bo$3o!

Obviously this fails to be a valid RLE in the existing format. It is a different format. That's fine; there is no need to change the existing widely supported RLE format merely to make it slightly easier to type patterns by hand.

Databases like 5S also define and use some internal format, often "one pattern per line", including both the rulestring and the pattern data.

[confocaloid]

EDIT: moved a question into another thread, by crossposting.
viewtopic.php?f=7&t=6765

[Vort]

(What is the longest-lived known 3G collision?)

This one, maybe?

Beyond the 500,000th collision (or so) we get really quickly diminishing returns on the effort of enumerating further collisions and hashing every generation. How often is someone really actually in practice going to want to be able to look up, say, the 999th generation of collisions like the one shown here?

It depends on what interesting properties particular collision can have.

Lifespan on its own does not look like interesting property.
First, because of glider-producing switch engine.
Second, because two-glider mess + glider can be tweaked for arbitrarily long lifespan.

It may be interesting, however, to count lifespan in non-traditional way, starting from a point, when last glider started interacting.
Another idea is to count ash population excluding cases with infinite growth.

I may be wrong or may be missing something, please correct me if so.

[WhiteHawk]

Why is this Eater variant not in the Eater stamp collection on the Wiki (lifted from a 1996 collection of eaters by Dean Hickerson)?

Code: Select all

x = 12, y = 9, rule = B3/S23
bo$2bo2b2ob2o$3obobobo2bo$5bo2bob2o$8bo$7b2o$4bobo2b2o$4b2o2bo2bo$9b2o!

It has a few benefits over the one in there already, especially with regards to side clearance, and it also has a smaller population.

Code: Select all

x = 30, y = 9, rule = LifeHistory
.A3.7D7.A3.5D2C$2.A2.2A.2A.D8.A2.2A.A2.C$3A.A.A.A2.A6.3A.A.A.2A$5.A2.
A.2A11.A2.A$8.A17.A$7.2A16.2A.A$4.A.A2.2AD10.A.A2.A.C$4.2A2.A2.A10.2A
2.A2.A$9.2A16.2A!

[hollowme]

I know conway's game of life is not reversible, but can any one state be found that generates a given board and has a min number of cells? Or at least close to min as possible?

Given a configuration like this:

`0 0 0 0 0 0`
`0 0 1 1 0 0`
`0 0 0 1 1 0`
`0 0 0 0 0 0`


A possible state that generates it is:

`0 0 0 0 0 0`
`0 0 1 1 0 0`
`0 0 0 1 0 0`
`0 0 0 1 0 0`

Another one is:

`0 0 0 0 0 0`
`0 0 1 1 0 0`
`0 0 0 1 0 0`
`1 0 0 1 0 0`

The first one being better in this case because has a fewer number of live cells in it.

I basically need to write an algorithm that finds a solution (the best one i can) in at max 300 secs and 8GB of memory and, if possible, faster than that. Right now I tried some forms of simulated annealing with little to no success and am trying to transition into some form of A\* but cant find a good enough heuristic

I’ve also saw that it’s possible to use CSP or SAT solvers but also had no success in it

[confocaloid]

I know conway's game of life is not reversible, but can any one state be found that generates a given board and has a min number of cells? Or at least close to min as possible?
[...]
I basically need to write an algorithm that finds a solution (the best one i can) in at max 300 secs and 8GB of memory and, if possible, faster than that. Right now I tried some forms of simulated annealing with little to no success and am trying to transition into some form of A\* but cant find a good enough heuristic

I’ve also saw that it’s possible to use CSP or SAT solvers but also had no success in it

As you wrote, it is possible to use SAT solvers, which perform fairly well as long as you do not attempt to "rewind" the pattern too far at once.
I suggest to check Logic Life Search, which can solve such problems, including population constraints.

[hollowme]

Thanks! I’ll take a look. The problem I found with sat solvers, at least the way I used em, was that even though they find a valid board, there is no guarantee it’s a minimal one, so I ended up minimizing the whole search space still, which is exponential in the size of the input.

Basically I’m given a random matrix ranging from 1x1 to 25x25 and have to find the minimal immediate predecessor. Finding one I managed to do and with exhaustive search I can find the minimal, it just takes too much memory and time 🫠

[hotdogPi]

We've recently found that minimal isn't always optimal. Minimal tends to give isolated dots, which can sometimes be tricky when backing up a second generation.

EDIT: I think the 32 below is actually better than the 29. Try backing each of them up once and see what you get. I suspect it will be easier for the 32.

[confocaloid]

Thanks! I’ll take a look. The problem I found with sat solvers, at least the way I used em, was that even though they find a valid board, there is no guarantee it’s a minimal one, so I ended up minimizing the whole search space still, which is exponential in the size of the input.

Basically I’m given a random matrix ranging from 1x1 to 25x25 and have to find the minimal immediate predecessor. Finding one I managed to do and with exhaustive search I can find the minimal, it just takes too much memory and time 🫠

You can run a SAT solver repeatedly, decrementing upper bound on population, until you get "unsatisfiable".

With the following input file:

Code: Select all

* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *

0 0 0 0 0 0 0 0 0 0
0 1 1 1 1 1 1 1 1 0
0 1 1 1 0 0 1 1 1 0
0 1 1 1 0 0 1 1 1 0
0 1 1 1 1 1 0 0 1 0
0 1 1 1 1 1 0 0 1 0
0 1 0 0 0 0 0 0 1 0
0 1 0 0 0 0 0 0 1 0
0 1 1 1 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0

The following LLS command finds some solution:

Code: Select all

# python3 lls test.txt

Here is the first solution I found:

Code: Select all

x = 10, y = 10, rule = B3/S23
5bo$b2o3bob2o$2b2obobo2$obo4b2o$bob6o$5bo$b2obo2bo$o7b2o$3bob2o!

The population is 32, so I can run again with population bound "<32":

Code: Select all

# python3 lls test.txt -p '<32'

and so on.

In this case, I found a solution with 29 alive cells, but no solution with 28 alive cells:

Code: Select all

x = 12, y = 12, rule = B3/S23
bbbbbbbbbbbb$
bbbbbobbbbbb$
boobobboobbb$
bbbobobboobb$
bbbbbbbbbbbb$
bboobbobobbb$
bbboboobobob$
bbbbbbbbbbbb$
boboboobobbb$
bbobbbbbboob$
bbbbobbobbbb$
bbbbbbbbbbbb!

[hollowme]

I’ll check the links and lls, thanks for the help! Btw, I’ve seen it’s written in python, is there a similar one in C? I can only use C for this assignment

[hotdogPi]

Wait, this is an assignment? You're supposed to write your own code in programming classes, not find other people's existing code.

[hollowme]

I did! now, for better solutions we were cleared to use any existing solution, including SAT solvers and what not. It’s an AI class, hence the algorithms for exhaustive search, A* etc

Plus, I’m not really looking for a pre made solution, just a path to follow since I don’t really know where to go from where I am.

[Tawal]

I'd rather deliberate here than create a pointless topic.

I think it might be interesting to list the 2 SL Factories for at least 2 reasons :
- there are enough 2SL OTTs to check.
- the 2SL constellation could substitute primordial Still Lives for conduits/converters/reactions.

Here's an example (a bad one, as there are no functional conduits to append) :

Code: Select all

x = 33, y = 41, rule = LifeHistory
2.4B$3.4B$4.4B$5.4B$6.4B$7.4B$8.4B$9.4B$10.4B$11.4B$12.4B$13.4B$11.7B
13.2A$10.9B12.A$10.2B3E5B3.2B3.BA.A$9.5B2E11B.B2A$8.5B2E14B$7.12B2D4B
D3B$6.13B2D3BDBD2B$5.18BD2BDB$6.18B2D$4.13B.4B$4.2A3.13B$5.A3.12B$2.
3A5.2B.6B$2.A11.4B$13.4B$12.4B$11.4B$10.4B$9.4B$8.4B$7.4B$6.4B$5.4B$
4.4B$3.4B$2.4B$.2A2B$ABAB$.BA!

So, the question is: Do you think it would be useful to reference these factories ?

Edit:
Another reason could be confocaloid's attempt at a switch.
A 2 Blocks factory could offer other openings...

[confocaloid]

In general, there are just way too many 2-object stable constellations. Most of them are not involved in any known "interesting" reaction.

There might be an interesting reaction involving some particular 2-object stable constellation. For example, as you wrote, there may be an one-time turner.
Even then, one needs (at least) to mention any such reaction in the post, to explain why and how the factory may be useful.

[...]
Here's an example (a bad one, as there are no functional conduits to append) :

Code: Select all

x = 33, y = 41, rule = LifeHistory
2.4B$3.4B$4.4B$5.4B$6.4B$7.4B$8.4B$9.4B$10.4B$11.4B$12.4B$13.4B$11.7B
13.2A$10.9B12.A$10.2B3E5B3.2B3.BA.A$9.5B2E11B.B2A$8.5B2E14B$7.12B2D4B
D3B$6.13B2D3BDBD2B$5.18BD2BDB$6.18B2D$4.13B.4B$4.2A3.13B$5.A3.12B$2.
3A5.2B.6B$2.A11.4B$13.4B$12.4B$11.4B$10.4B$9.4B$8.4B$7.4B$6.4B$5.4B$
4.4B$3.4B$2.4B$.2A2B$ABAB$.BA!

[...]

In your example, even if one finds a conduit that can feed the E-heptomino in, the result will still be of limited usefulness.
A problem is that the input glider lane is not "transparent by default" (the glider hits the rightmost eater 1, as shown below).
If the glider lane was "transparent by default", then the factory could potentially be useful as a demultiplexer. Even then, there are already several known devices of that kind (which can be useful and deserve to be collected).

Code: Select all

x = 73, y = 41, rule = LifeHistory
2.4B36.4B$3.4B36.4B$4.4B36.4B$5.4B36.4B$6.4B36.4B$7.4B36.4B$8.4B36.4B
$9.4B36.4B$10.4B36.4B$11.4B36.4B$12.4B36.4B$13.4B36.4B$11.7B13.2A18.
7B13.2A$10.9B12.A18.9B12.A$10.2B3E5B3.2B3.BA.A18.2B3D5B3.2B3.BA.A$9.
5B2E11B.B2A18.5B2D11B.B2A$8.5B2E14B19.5B2D14B$7.12B2D4BD3B18.12B2D4BD
3B$6.13B2D3BDBD2B17.13B2D3BDBD2B$5.18BD2BDB17.18BD2BDB$6.18B2D20.18B
2D$4.13B.4B22.13B.4B$4.2A3.13B22.2A3.13B$5.A3.12B24.A3.12B$2.3A5.2B.
6B23.3A5.2B.6B$2.A11.4B24.A11.4B$13.4B36.4B$12.4B36.4B$11.4B36.4B$10.
4B36.4B$9.4B36.4B$8.4B36.4B$7.4B36.4B$6.4B36.4B$5.4B36.4B$4.4B36.4B$
3.4B36.4B$2.4B36.4B$.2A2B36.2A2B$ABAB36.ABAB$.BA38.BA!

[Tawal]

Thanks for your answer.
I understand your purpose.
I also understand that this kind of fitting is very luckier.
But, look, you found a SL factory that fit with 2 Blocks of Galumpher.
Ok, no new thread. But who check/care to this kind of possibilities ?
Now, when I find a 2SL factory, I check if the constellation is or not an OTT.



Another, subject.
I see this pattern called "Thorn" :

Code: Select all

x = 5, y = 4, rule = B3/S23
3b2o$4bo$o3bo$b3o!

It's also this object : xs14_33yi696zy0cc
Do we have some X to "Thorn"
Because I also see some "Thorn" to X …

[confocaloid]

[...] It's also this object : xs14_33yi696zy0cc [...]

xs14_33yi696zy0cc isn't "Thorn".

Instead, "Thorn" is a proposed name for the following pattern specifically:

i'm proposing that we name this pattern Thorn, after the Old English letter þ

Code: Select all

x = 5, y = 4, rule = B3/S23
3b2o$4bo$o3bo$b3o!

[...] Do we have some X to "Thorn"
Because I also see some "Thorn" to X …

In general, one could ask "What are currently known X-to-A converters" for any choice of an active object A.

For some active objects A (Herschel, B-heptomino, pi-heptomino, ...) there are many known X-to-A, there are many known A-to-X, and there are enough possible connections for those converters, so that the active object A becomes sufficiently versatile for use in larger constructions.

For other active objects, there are few currently known converters, and few or no connectable converters. This means those active objects aren't currently known to be versatile enough to make them useful for larger constructions.

There are infinitely many active objects. (Just enumerate all unstable objects via brute-force enumeration.) However, only a few active objects are currently known to be sufficiently versatile.

As far as I know, "Thorn" isn't currently known to be versatile enough for use as a "connection point" in larger constructions.

[...]
But, look, you found a SL factory that fit with 2 Blocks of Galumpher.
Ok, no new thread. But who check/care to this kind of possibilities ?
Now, when I find a 2SL factory, I check if the constellation is or not an OTT.
[...]

I'm not sure whether I understand the [intended idea behind the] question. Can you explain what you mean here?

You mentioned a SL factory and the Galumpher, so here is what appears to be the relevant post.

Note that I didn't really discover anything new here. I merely looked up a known block factory that can install the bait block into the Galumpher, without interfering with the functionality of Galumpher. Even then, by itself this is not too useful, because
(a) if installing the bait block is "one-time" then a small one-glider seed for the block would suffice,
(b) on the other hand, if one needs ability to add/remove the bait block repeatedly, then this particular block factory will not work due to failing to leave the Galumpher's input glider lane transparent when the block is absent.

[...]
The main idea is just this. As shown, it is incomplete. The left side works as intended; the block factory can be used to install the bait block, and the Galumpher (with the bait block present) is functional. However, the right side fails, because the input glider lane is not transparent when the Galumpher's bait block is absent.

Ideally, there would be an easy way to add the bait block, and an easy way to remove the bait block, and the device would either reflect input gliders back along the same path (as the Galumpher) or let input gliders pass through (as empty space) depending on whether the bait block is present or absent.

Code: Select all

x = 130, y = 75, rule = LifeHistory
11.2A.2A65.2A.2A$12.A.A67.A.A$7.2A.A5.A.2A57.2A.A5.A.2A$6.A.A.2A3.2A.
A.A55.A.A.2A3.2A.A.A$5.A2.B2.BA.AB2.B2.A53.A2.B2.BA.AB2.B2.A$5.7AB.B
7A53.7AB.B7A$9.3B.B.3B61.3B.B.3B$7.3AB.3B.B3A57.3AB.3B.B3A$6.A.BA3BA
3BAB.A55.A.BA3BA3BAB.A$6.2A3.BABAB3.2A55.2A3.BABAB3.2A$11.BABAB65.BAB
AB$11.2BA2B65.2BA2B$11.2B.2B65.2B.2B$9.B.5B63.B.5B$7.9B61.9B$7.8B2A
60.8B2A$6.2A6BA2BA4.A53.2A6BA2BA4.A$6.2AB.5B2AB3.A.A52.2AB.5B2AB3.A.A
$7.B2.8B2.2BAB53.B2.8B2.2BAB$10.8B3.2B57.8B3.2B$11.8B.2B59.8B.2B$11.
13B57.13B$11.15B55.15B$9.17B53.17B$7.18B52.18B$7.2BC15B52.2BD15B$6.3B
CBC11B53.3BDBD11B$7.2B3C11B54.2B3D11B$6.5BC11B2.2A49.5BD11B2.2A$5.18B
.B2A2B46.18B.B2A2B$4.4B7.8B2.4B45.4B7.8B2.4B$4.3B8.14B45.3B8.14B$2.4B
9.14B43.4B9.14B$2.2CB10.7B2D4B44.2CB10.7B2D4B$3.C6.2B3.7B2D5B4.2B38.C
6.2B3.7B2D5B4.2B$3C4.6B.B.13B.B.6B32.3C4.6B.B.13B.B.6B$C6.31B32.C6.
31B$6.33B37.33B$7.31B39.31B$7.31B39.31B$5.32B38.32B$5.33B37.33B$4.2A
33B35.2A33B$4.2A33B35.2A33B$5.B.32B36.B.32B$7.12B.17B.B2A36.12B.17B.B
2A$8.2B.25B2.BA.A36.2B.25B2.BA.A$12.24B5.A40.24B5.A$12.24B5.2A39.24B
5.2A$12.25B45.25B$8.A.2A21B.4B40.A.2A21B.4B$6.3AB2AB2.18B2.4B37.3AB2A
B2.18B2.4B$5.A4.B5.17B3.4B35.A4.B5.17B3.4B$6.3A.2A4.B2.14B4.4B35.3A.
2A4.B2.14B4.4B$8.A.A4.2A2.13B6.4B36.A.A4.2A2.13B6.4B$8.A.A4.A4.5B2.4B
8.4B35.A.A4.A4.5B2.4B8.4B$9.A3.A.A6.B5.5B7.4B35.A3.A.A6.B5.5B7.4B$13.
2A6.3B7.2A8.4B38.2A6.3B7.2A8.4B$21.B2AB6.A10.4B45.B2AB6.A10.4B$22.2A
8.3A8.4B45.2A8.3A8.4B$34.A9.4B56.A9.4B$45.4B66.4B$46.4B66.4B$47.4B66.
4B$48.3B67.3B8$57.3A67.3A$57.A69.A$58.A69.A!

[Vort]

Is there a well defined and generally accepted method for determining at which tick glider collision starts (assuming gliders coming from infinity)?
(For example, boolean function, which accepts pattern rle of approaching gliders and returns true if they started to collide)

[Tawal]

…

For other active objects, there are few currently known converters, and few or no connectable converters. This means those active objects aren't currently known to
be versatile enough to make them useful for larger constructions.

There are infinitely many active objects. (Just enumerate all unstable objects via brute-force enumeration.) However, only a few active objects are currently known to be sufficiently versatile.

As far as I know, "Thorn" isn't currently known to be versatile enough for use as a "connection point" in larger constructions.

Thank you for these clarifications on active regions.

[...]
But, look, you found a SL factory that fit with 2 Blocks of Galumpher.
Ok, no new thread. But who check/care to this kind of possibilities ?
Now, when I find a 2SL factory, I check if the constellation is or not an OTT.
[...]

I'm not sure whether I understand the [intended idea behind the] question. Can you explain what you mean here?

It was just to point out that sometimes (with some luck) 2 completely different conduits can have 2 or more SL in same location respectively.
Before I'm wondering about that, I only keep the 1SL factories. Now, when I find a 2SL factory, I check if the 2SL constellation is or not an OTT.
Sometimes, when the clearance is good, I also test some Glider collisions.

[confocaloid]

[...] There are infinitely many active objects. (Just enumerate all unstable objects via brute-force enumeration.) However, only a few active objects are currently known to be sufficiently versatile. [...]

It was just to point out that sometimes (with some luck) 2 completely different conduits can have 2 or more SL in same location respectively.
Before I'm wondering about that, I only keep the 1SL factories. Now, when I find a 2SL factory, I check if the 2SL constellation is or not an OTT.
Sometimes, when the clearance is good, I also test some Glider collisions.

The main reason to not attempt the "collect all A-to-two-still-lives factories" is the same as the main reason to not attempt the "collect all X-to-Y conduits ignoring connectability".

The main reason is practical. There are lots and lots of possibilities.
Only a small number of those possibilities lead to results that can be used in the most likely expected way
(for example, a X-to-Y conduit that can actually be preceded by a known A1-to-X and can be followed by a known Y-to-A2;
or a A-to-two-still-lives factory that happens to be useful to complete an already known partial).
Checking all possibilities to see whether something work takes time and human efforts, unless someone manages a way to do it completely automatically.

So, when you write "sometimes (with some luck)", I think you might be underestimating how much luck one needs, and/or overestimating the willingness of most people to (semi-manually or manually) gold-rush through hundreds or thousands of possibilities before finding one or two lucky completions with limited applicability.

[confocaloid]

Is there a well defined and generally accepted method for determining at which tick glider collision starts (assuming gliders coming from infinity)?
(For example, boolean function, which accepts pattern rle of approaching gliders and returns true if they started to collide)

"Well-defined", likely yes. "Generally accepted", perhaps no.

I would start with a rewound collision, where all the colliding gliders are well-separated.
One needs to define 'well-separated'. Note that both shapes of the glider have bounding box 3-by-3. Surround every glider by a layer of dead cells, resulting in a 5-by-5 "tile". Define well-separated by requiring that these 5-by-5 "tiles" should not overlap with each other.

Code: Select all

x = 15, y = 5, rule = LifeHistory
5B5.5B$BDCDB5.BC2DB$B2DCB5.BD2CB$B3CB5.B2CDB$5B5.5B!
#C [[ GRID VIEWONLY ]]

Then evolve the rewound collision one tick at a time, until you have a generation where some gliders are no longer well-separated. That means the last tick that happened was the beginning of the collision, and the preceding generation is the last generation before collision.

For example, with the above approach,

• the following two-glider collision takes 20 ticks before gliders collide.
• Generation 19 is the last generation before collision.
• Generation 20 contains gliders that aren't well-separated.

Code: Select all

x = 17, y = 3, rule = B3/S23
2bo13bo$obo11b2o$b2o12b2o!
#C [[ THEME Caterer GRID ZOOM 12 STOP 19 HARDRESET ]]

In general (for other spaceships or objects), every colliding object would have to be surrounded by a layer of dead neighbours (i.e. the tiles would be the neighbourhoods of the colliding objects). If the neighbourhoods of colliding objects are pairwise nonintersecting, then the colliding objects are well-separated, and the collision did not yet begin.

[dvgrn]

"Well-defined", likely yes. "Generally accepted", perhaps no.

Yup -- in fact, this problem just came up in the 3-glider collision rework project.

I wanted to rewind all of the 3G collisions to 16 ticks before the collision started. But the definition I used for when the collision started, doesn't always match confocaloid's definition above -- because it doesn't involve the concept of "well-separated" gliders.

... it's always safe to run these patterns for 16 ticks, and the gliders will remain recognizable and undamaged. Some of them may be in contact with each other right at T=16, but no births will be suppressed and no non-glider births will have happened yet.

The definition of "collision" that I used there is equally well-defined, but also not in any way generally accepted. The idea is that a collision starts on the first tick when cells are born or cells fail to be born, in a way that wouldn't happen if each glider were tracked independently.

I.e., a collision can safely be said to have happened when a pattern consisting of two or more objects first diverges from the superposition of those same objects evolved in separate universes. By that definition, the gliders in confocaloid's example haven't collided yet at T=20, but they have collided at T=21.

I don't think the precise definition that confocaloid mentions above has ever been used before in practice (where generation 19 in the pattern above is the "last generation before collision"). The criterion of the 5x5 tiles overlapping would claim a collision in quite a lot of cases where no interaction between the gliders ever happens at all:

Code: Select all

x = 38, y = 18, rule = LifeHistory
4.5B15.5B$4.2BA2B15.2BA2B$4.3BAB15.3BAB$4.B3AB15.B3AB$9B11.9B$2BA2B15.
B2A2B$3BAB15.BABAB$B3AB15.BA3B$5B15.5B$13.5B15.5B$13.2BA2B15.2BA2B$13.
3BAB15.3BAB$9.5B3AB15.B3AB$9.2BA6B12.8B$9.3BAB16.B2A2B$9.B3AB16.BABAB
$9.5B16.BA3B$30.5B!

There are various ways of patching up this problem, but there's no one really good or obviously "right" solution, I think.

[confocaloid]

[...] The criterion of the 5x5 tiles overlapping would claim a collision in quite a lot of cases where no interaction between the gliders ever happens at all: [...]

Clarification: what I attempted to describe in my previous post is not a definition of "collision". Instead, it is a possible definition of "last generation before collision", intended to work in a useful way at least for all actual collisions.

To decide/define whether or not some pattern is a glider collision, one can indeed
(a) evolve each individual glider in the pattern separately and combine the results,
(b) evolve the entire pattern,
(c) check whether or not at some time in future either some evolved gliders intersect with each other (as sets of alive cells), or else the evolution of the pattern (= the evolved combination of the initial gliders) diverges from the combination of the evolved gliders.

However, that does not necessarily mean the same approach should be used to decide when the collision happens, in case it happens at all.

[Vort]

Thanks for the answer!

...
One needs to define 'well-separated'. Note that both shapes of the glider have bounding box 3-by-3. Surround every glider by a layer of dead cells, resulting in a 5-by-5 "tile". Define well-separated by requiring that these 5-by-5 "tiles" should not overlap with each other.

Code: Select all

x = 15, y = 5, rule = LifeHistory
5B5.5B$BDCDB5.BC2DB$B2DCB5.BD2CB$B3CB5.B2CDB$5B5.5B!
#C [[ GRID VIEWONLY ]]

...

Will dilation work equally well?
Such collision detection will be more computationally intensive, but will there be any problems aside from that?

Code: Select all

x = 15, y = 5, rule = LifeHistory
.3B6.3B$.BC2B5.BC3B$3BCB5.2B2CB$B3CB5.B2C2B$5B5.4B!
#C [[ GRID VIEWONLY ]]

(Probably, dilation is not the perfect term, I knew about this algorithm before, but forgot it now and Googled by its description)

[confocaloid]

Such collision detection will be more computationally intensive, but will there be any problems aside from that?

One potential problem is that (as mentioned in earlier discussions) sometimes a glider salvo will have to be treated as a single "object":

Code: Select all

x = 9, y = 8, rule = LifeHistory
4.3B$4.BC3B$4.2B2CB$.4B2C2B$.BCBD3B$3BCB$B3CB$5B!
#C [[ GRID ZOOM 10 ]]

Although that may actually become an useful way of grouping collisions, for example distinguishing between those three-glider collisions where two gliders are very close to each other, and all other two-directional three-glider collisions where the gliders are initially pairwise well-separated.