Code: Select all
x = 8, y = 10, rule = B3/S23
2bo$3b2ob2o$2b2o2b2o6$2o4b2o$2o4b2o!
Code: Select all
x = 11, y = 12, rule = B3/S23
4bo$3b3o$2b2ob2o$b2o$3o$b2o$2b2ob2o$3b3o$4bo2$3b2o4b2o$3b2o4b2o!
Is it a bug or normal behaviour ?
Code: Select all
x = 8, y = 10, rule = B3/S23
2bo$3b2ob2o$2b2o2b2o6$2o4b2o$2o4b2o!
Code: Select all
x = 11, y = 12, rule = B3/S23
4bo$3b3o$2b2ob2o$b2o$3o$b2o$2b2ob2o$3b3o$4bo2$3b2o4b2o$3b2o4b2o!
Seems like three-block shifter is indeed missing. I unsuccessfully tried to lookup each of 8 orientations of another phase.vilc wrote: ↑April 7th, 2024, 1:02 pmThe Three-block shifter reaction doesn't seem to be in the octo3obj database.The following pattern yields no result with find-by-octo3.py :Code: Select all
x = 8, y = 10, rule = B3/S23 2bo$3b2ob2o$2b2o2b2o6$2o4b2o$2o4b2o!
I wrote a script to parse the collisions in a different way and didn't find it either.Code: Select all
x = 11, y = 12, rule = B3/S23 4bo$3b3o$2b2ob2o$b2o$3o$b2o$2b2ob2o$3b3o$4bo2$3b2o4b2o$3b2o4b2o!
Is it a bug or normal behaviour ?
Code: Select all
x = 8, y = 9, rule = B3/S23
2o3bo$2ob2o$4b2o5$2o4b2o$2o4b2o!
Yup, I'm thinking that has to count as a bug -- maybe in my collision enumeration code, or in some kind of post-enumeration simplification step?confocaloid wrote: ↑April 7th, 2024, 1:46 pmSeems like three-block shifter is indeed missing. I unsuccessfully tried to lookup each of 8 orientations of another phase.
It should be in octo3obj, because a "nearby" collision (same 3-block constellation) is there:Code: Select all
x = 8, y = 9, rule = B3/S23 2o3bo$2ob2o$4b2o5$2o4b2o$2o4b2o!
Maybe it would solve the question "what happened with that particular collision" but it may fail to solve the larger question "what happened", and it will not solve the question of independent verification.dvgrn wrote: ↑April 7th, 2024, 6:40 pm[...]
The generating code for those fingerprint files is mostly all available in the repository, so re-generating the database -- while keeping an eye out for what happens with that particular collision -- would presumably solve the mystery eventually.
I'm having some problems using "find-full-participation-collisions_v3.py". Where can I find the ruletables for "Interaction-test" and "Interaction-prep"?dvgrn wrote: ↑April 7th, 2024, 6:40 pmThe generating code for those fingerprint files is mostly all available in the repository, so re-generating the database -- while keeping an eye out for what happens with that particular collision -- would presumably solve the mystery eventually.
Hmm. That might need some forensic work on old backups, though I remember what they did and could _probably_ rewrite them correctly from scratch. I'll be able to look in the most likely location in an hour or so, and will update this post.
... That said, the octohash databases are so much less efficient than they could be, that maybe it makes more sense to re-work the whole process from the ground up -- generate enumerations of constellations and collisions with C++, let's say, and then hopefully move the resulting indexed databases to some queryable online location.I plan to update this README with a walkthrough of the full process of generating a new octohash database, whenever I get around to fingerprinting wildmyron's version of the 3G/4G SJK database (duplicates removed by using canonical Shinjuku glider-collision format to store the 3G and 4G collisions.)
I will try to do this, I already had some C++ code for the collisions of a glider and a p1 target.
Aha, yes! The explanation for that surprisingly small number of collisions ... is also the reason why the three-block shifter isn't in octo3obj.vilc wrote: ↑April 8th, 2024, 4:39 pmI continued the investigations on the current octo3obj database. "buildconst3obj-comments.py" generated 1,624,450 constellations of three objects in a 11x11 bounding box. Does it mean that less than three collisions on average were stored for each orientation of each constellation ? I must be missing something.
Code: Select all
x = 8, y = 10, rule = B3/S23
2bo$3b2ob2o$2b2o2b2o6$2o$2o!
Code: Select all
x = 11, y = 12, rule = B3/S23
2bo$3b2ob2o$2b2o2b2o6$2o6b2o$2o5bo2bo$7bo2bo$8b2o!
Sorry, that was the basic idea, but some of the details weren't quite right.dvgrn wrote: ↑April 8th, 2024, 6:05 pmThat's what the "Interaction-test" and "Interaction-prep" rules are about. I colored all of the stationary objects one color to start out, and the glider another "plague" color, and made it so that even a temporary touch from glider cells will spread the "plague" color to the stationary objects. Then after running the required number of ticks, I ran the Interaction-test rule, removing all of the "plague" cells.
If the resulting population was greater than zero, I didn't index that particular collision with that particular constellation -- because at least one of the objects in the constellation never got touched by the active reaction, so in some sense there was "nothing new" happening there that did not also happen somewhere else in the enumeration.
Most likely configurable bounding box and the number of "objects". Probably also configurable types of "objects" (effectively specifying which multisets/bags of "objects" should be included). And maybe also configurable type of the hitting spaceship (so one could choose glider/LWSS/MWSS/HWSS / glider pair / ...).
Yup, that's a really good use case to keep in mind -- or even gliders hitting LeapLife constellations. In Life you can assume that nothing interesting will happen if a glider stays two diagonal cells away from the closest live cell in a constellation, but in rules like LeapLife there's still an interaction on those lanes.confocaloid wrote: ↑April 9th, 2024, 1:54 amEven better if the code would work for alien objects and alien spaceships in other rules. E.g. hitting 10x10 Blockic constellations with a lepa in LeapLife.
My apologies for losing track of those rules! They should have been checked in to the repo along with everything else. If you do rebuild them, please post a copy and I'll test them out and add them to the repo.
Here they are, along with the rule trees (feel free to correct any mistake in the comments). They seem to work correctly according to your description and on the script's end : now it discard around three-quarters of the collisions, a reasonnable value given my estimates (a little too low, perhaps).
Code: Select all
@RULE Interaction-prep
Helper rule to convert state 1 cells to state 3 cells.
@TABLE
n_states:4
neighborhood:vonNeumann
symmetries:permute
var a = {0,1,2,3}
var b = {a}
var c = {a}
var d = {a}
1,a,b,c,d,3
@TREE
num_states=4
num_neighbors=4
num_nodes=5
1 0 3 2 3
2 0 0 0 0
3 1 1 1 1
4 2 2 2 2
5 3 3 3 3
Code: Select all
@RULE Interaction-test
State 1 and state 3 patterns each follow B3/S23 as long as they don't interact.
If there is an interaction, state 3 patterns gradually become state 1
(with some help from state 2 if there is no direct contact).
@TABLE
n_states:4
neighborhood:Moore
symmetries:permute
var a = {1,3}
var b = {a}
var c = {a}
var d = {a}
var e = {a}
var f = {a}
var g = {a}
var h = {a}
var i = {a}
var o1 = {0,2}
var o2 = {o1}
var o3 = {o1}
var o4 = {o1}
var o5 = {o1}
var o6 = {o1}
var o7 = {o1}
var o8 = {o1}
var o9 = {o1}
var any1 = {0,1,2,3}
var any2 = {any1}
var any3 = {any1}
var any4 = {any1}
var any5 = {any1}
var any6 = {any1}
var any7 = {any1}
var any8 = {any1}
var any9 = {any1}
# surviving live cells become state 1, except if only state 3 and state 0 cells are involved
3,3,3,0,0,0,0,0,0,3
3,3,3,3,0,0,0,0,0,3
a,b,c,o1,o2,o3,o4,o5,o6,1
a,b,c,d,o1,o2,o3,o4,o5,1
# underpopulated or overpopulated live cells die
a,o1,o2,o3,o4,o5,o6,o7,o8,0
a,b,o1,o2,o3,o4,o5,o6,o7,0
a,b,c,d,e,o1,o2,o3,o4,0
a,b,c,d,e,f,o1,o2,o3,0
a,b,c,d,e,f,g,o1,o2,0
a,b,c,d,e,f,g,h,o1,0
a,b,c,d,e,f,g,h,i,0
# dead cells with three living neighbours become state 1 except when only state 3 and state 0 cells are involved
0,3,3,3,0,0,0,0,0,3
o1,a,b,c,o2,o3,o4,o5,o6,1
# overpopulated dead cells become state 2 only when the middle cell is state 0
# and some state 1 and state 3 cells are involved
0,1,3,d,e,o1,o2,o3,o4,2
0,1,3,d,e,f,o1,o2,o3,2
0,1,3,d,e,f,g,o1,o2,2
0,1,3,d,e,f,g,h,o1,2
0,1,3,d,e,f,g,h,i,2
o1,a,b,c,d,o1,o2,o3,o4,0
o1,a,b,c,d,e,o1,o2,o3,0
o1,a,b,c,d,e,f,o1,o2,0
o1,a,b,c,d,e,f,g,o1,0
o1,a,b,c,d,e,f,g,h,0
# otherwise, state 2 cells die
2,any1,any2,any3,any4,any5,any6,any7,any8,0
@TREE
num_states=4
num_neighbors=8
num_nodes=90
1 0 0 0 0
2 0 0 0 0
1 0 1 0 1
2 0 2 0 2
1 0 1 0 3
2 0 2 0 4
3 1 3 1 5
1 1 1 1 1
2 2 7 2 7
3 3 8 3 8
3 1 3 1 3
1 3 1 1 3
2 4 7 2 11
3 5 8 3 12
4 6 9 10 13
1 2 0 0 0
2 7 0 7 15
2 7 15 7 15
3 8 16 8 17
3 8 17 8 17
4 9 18 9 19
4 10 9 10 9
2 11 15 7 0
3 12 17 8 22
4 13 19 9 23
5 14 20 21 24
2 0 0 0 15
2 15 15 15 15
3 16 26 16 27
3 17 27 17 27
4 18 28 18 29
4 19 29 19 29
5 20 30 20 31
2 7 15 7 0
3 8 17 8 33
4 9 19 9 34
5 21 20 21 35
2 0 15 0 0
3 22 27 33 37
4 23 29 34 38
5 24 31 35 39
6 25 32 36 40
3 26 26 26 27
3 27 27 27 27
4 28 42 28 43
4 29 43 29 43
5 30 44 30 45
5 31 45 31 45
6 32 46 32 47
3 33 27 33 37
4 34 29 34 49
5 35 31 35 50
6 36 32 36 51
3 37 27 37 37
4 38 43 49 53
5 39 45 50 54
6 40 47 51 55
7 41 48 52 56
4 42 42 42 43
4 43 43 43 43
5 44 58 44 59
5 45 59 45 59
6 46 60 46 61
6 47 61 47 61
7 48 62 48 63
4 49 43 49 53
5 50 45 50 65
6 51 47 51 66
7 52 48 52 67
4 53 43 53 53
5 54 59 65 69
6 55 61 66 70
7 56 63 67 71
8 57 64 68 72
5 58 58 58 59
5 59 59 59 59
6 60 74 60 75
6 61 75 61 75
7 62 76 62 77
7 63 77 63 77
8 64 78 64 79
5 65 59 65 69
6 66 61 66 81
7 67 63 67 82
8 68 64 68 83
5 69 59 69 69
6 70 75 81 85
7 71 77 82 86
8 72 79 83 87
9 73 80 84 88
@COLORS
1 0 255 0
2 0 0 128
3 216 255 216
Code: Select all
x = 182, y = 40, rule = Interaction-test
90.4A3.10A4.A3.4A$93.2A.A6.A.2A2.A2.A2.A.A34.4C3.10C4.C3.4C$89.2A2.3A
2.5A.A.A.2A3.2A.2A37.2C.C6.C.2C2.C2.C2.C.C$90.2A2.A4.A.2A.A3.A3.6A.A
31.2C2.3C2.5C.C.C.2C3.2C.2C$89.2A.A3.2A7.A2.A4.A.A2.A33.2C2.C4.C.2C.C
3.C3.6C.C$90.A.3A4.2A2.A.2A.2A.A3.5A31.2C.C3.2C7.C2.C4.C.C2.C$90.A2.
2A.7A.A.A2.A4.6A32.C.3C4.2C2.C.2C.2C.C3.5C$91.A4.2A.2A2.A2.2A.A2.A.2A
.A.A32.C2.2C.7C.C.C2.C4.6C$89.3A3.A2.A.3A3.A3.A2.A.3A35.C4.2C.2C2.C2.
2C.C2.C.2C.C.C$92.A.A3.A2.A.2A3.2A2.A2.4A32.3C3.C2.C.3C3.C3.C2.C.3C$
89.A2.2A.A2.5A.A.3A.A2.A.5A34.C.C3.C2.C.2C3.2C2.C2.4C$89.3A3.3A.6A6.
3A.A2.2A31.C2.2C.C2.5C.C.3C.C2.C.5C$89.A.A3.2A.2A.A.3A3.A.2A.A.2A33.
3C3.3C.6C6.3C.C2.2C$92.A2.A2.A2.3A.5A2.A.3A.2A31.C.C3.2C.2C.C.3C3.C.
2C.C.2C$3.A13.A71.2A.A2.2A.A2.2A.A.A.A2.A.2A.A.2A34.C2.C2.C2.3C.5C2.C
.3C.2C$4.A13.A27.10A34.2A2.2A.A2.4A4.A.A2.2A4.A31.2C.C2.2C.C2.2C.C.C.
C2.C.2C.C.2C$2.3A11.3A70.A2.A.7A2.A.A4.2A2.A4.A32.2C2.2C.C2.4C4.C.C2.
2C4.C$90.3A.A.A6.2A.A.A2.A3.A.2A32.C2.C.7C2.C.C4.2C2.C4.C$89.2A3.4A2.
2A3.2A.4A.A2.A.2A32.3C.C.C6.2C.C.C2.C3.C.2C$2C13.2C33.2C39.A2.3A5.A4.
A.4A.A4.A31.2C3.4C2.2C3.2C.4C.C2.C.2C$2C13.2C33.2C42.A.A5.2A.A.2A.2A.
3A.A.A33.C2.3C5.C4.C.4C.C4.C$90.A2.4A3.2A2.A2.A.2A4.3A38.C.C5.2C.C.2C
.2C.3C.C.C$90.A.A4.A2.A2.3A.A2.2A2.2A.2A33.C2.4C3.2C2.C2.C.2C4.3C$91.
2A2.A.6A.7A.A4.A.A32.C.C4.C2.C2.3C.C2.2C2.2C.2C$89.2A.A3.3A2.A2.6A.9A
33.2C2.C.6C.7C.C4.C.C$89.A2.A.A.A.A2.3A.A3.A2.4A2.2A31.2C.C3.3C2.C2.
6C.9C$151.C2.C.C.C.C2.3C.C3.C2.4C2.2C5$12.A$13.A$11.3A3$15.2C$15.C$
16.3C$18.C!
Hmm, that seems a bit slow. I remember it taking a few days, but not as long as a week, let alone a month.
"One month" was a quick (and rather pessimistic) estimate. I benchmarked more accurately (only running golly) and it reduces my estimate to 15 days.
Switching to HashLife doesn't change anything because Interaction-test implicitly runs with RuleLoader.
Good point, but lowering LONG_ENOUGH (even to 256 generations) only offers a few percents increase in speed.
Code: Select all
g.setrule("B12345678/S012345678")
neighbors=g.evolve(item,1)
g.setrule("B2345678/S012345678")
zone=g.evolve(neighbors,1)
Code: Select all
x = 11, y = 11, rule = B3/S23
bo$2bo$3o2$6b2o$6b2o3$3b2o3b2o$2bo2bobo2bo$3b2o3b2o!
Code: Select all
~/barrister$ make
clang++ -std=c++20 -Wall -Wextra -pedantic -O3 -DNDEBUG -march=native -mtune=native -flto -fno-stack-protector -fomit-frame-pointer -o Barrister Barrister.cpp -Wl,-stack_size -Wl,0x1000000
make: clang++: No such file or directory
make: *** [Makefile:20: Barrister] Error 127
Code: Select all
~/barrister$ make
clang++ -std=c++20 -Wall -Wextra -pedantic -O3 -DNDEBUG -march=native -mtune=native -flto -fno-stack-protector -fomit-frame-pointer -o Barrister Barrister.cpp -Wl,-stack_size -Wl,0x1000000
In file included from Barrister.cpp:13:
./LifeUnknownState.hpp:144:43: warning: unused parameter 'stable' [-Wunused-parameter]
void SanityCheck(const LifeStableState &stable) {
^
./LifeUnknownState.hpp:215:14: warning: unused variable 'on3' [-Wunused-variable]
uint64_t on3 = stateCount.bit3[i];
^
./LifeUnknownState.hpp:216:14: warning: unused variable 'on2' [-Wunused-variable]
uint64_t on2 = stateCount.bit2[i];
^
./LifeUnknownState.hpp:217:14: warning: unused variable 'on1' [-Wunused-variable]
uint64_t on1 = stateCount.bit1[i];
^
./LifeUnknownState.hpp:218:14: warning: unused variable 'on0' [-Wunused-variable]
uint64_t on0 = stateCount.bit0[i];
^
./LifeUnknownState.hpp:220:14: warning: unused variable 'unk3' [-Wunused-variable]
uint64_t unk3 = unknownCount.bit3[s][i];
^
./LifeUnknownState.hpp:221:14: warning: unused variable 'unk2' [-Wunused-variable]
uint64_t unk2 = unknownCount.bit2[s][i];
^
./LifeUnknownState.hpp:222:14: warning: unused variable 'unk1' [-Wunused-variable]
uint64_t unk1 = unknownCount.bit1[s][i];
^
./LifeUnknownState.hpp:223:14: warning: unused variable 'unk0' [-Wunused-variable]
uint64_t unk0 = unknownCount.bit0[s][i];
^
./LifeUnknownState.hpp:271:12: warning: unused variable 'stable_on' [-Wunused-variable]
uint64_t stable_on = stable.state[i];
^
./LifeUnknownState.hpp:265:12: warning: unused variable 'stateon' [-Wunused-variable]
uint64_t stateon = state[i];
^
./LifeUnknownState.hpp:267:12: warning: unused variable 'stateunkstable' [-Wunused-variable]
uint64_t stateunkstable = unknownStable[i];
^
./LifeUnknownState.hpp:272:12: warning: unused variable 'stable_unknown' [-Wunused-variable]
uint64_t stable_unknown = stable.unknown[i];
^
./LifeUnknownState.hpp:266:12: warning: unused variable 'stateunk' [-Wunused-variable]
uint64_t stateunk = unknown[i];
^
./LifeUnknownState.hpp:358:14: warning: unused variable 'on3' [-Wunused-variable]
uint64_t on3 = state3[i-1];
^
./LifeUnknownState.hpp:370:14: warning: unused variable 'stable_on' [-Wunused-variable]
uint64_t stable_on = nearbyStableState[i];
^
./LifeUnknownState.hpp:371:14: warning: unused variable 'stable_unknown' [-Wunused-variable]
uint64_t stable_unknown = nearbyStableUnknown[i];
^
In file included from Barrister.cpp:14:
./RotorDescription.hpp:26:13: warning: enumeration values 'NORESULT', 'STABLE', and 'OTHER' not handled in switch [-Wswitch]
switch (type) {
^~~~
./RotorDescription.hpp:51:48: warning: unused parameter 'resType' [-Wunused-parameter]
RotorType resType) {
^
./RotorDescription.hpp:86:13: warning: 8 enumeration values not handled in switch: 'ReflectAcrossXEven', 'ReflectAcrossYEven', 'Rotate90Even'... [-Wswitch]
switch (transf) {
^~~~~~
Barrister.cpp:300:22: warning: unused parameter 'everActive' [-Wunused-parameter]
const LifeState &everActive,
^
Barrister.cpp:301:51: warning: unused parameter 'activeTimer' [-Wunused-parameter]
const LifeCountdown<maxCellActiveWindowGens> &activeTimer,
^
Barrister.cpp:302:51: warning: unused parameter 'streakTimer' [-Wunused-parameter]
const LifeCountdown<maxCellActiveStreakGens> &streakTimer)
^
23 warnings generated.
/usr/bin/ld: Warning: grouped short command line options are deprecated: -stack_size
/usr/bin/ld: Error: unable to disambiguate: -stack_size (did you mean --stack_size ?)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:20: Barrister] Error 1
Probably it was computed by creating a text file with several generations (T = 0, 1, 2, 3) filled with asterisks, and with generation T = 4 specified to match the desired 20x18 predecessor. See "How to use LLS" here: viewtopic.php?p=55605#p55605
That's ... an extraordinarily vague problem description. There are lots of subtle things that can go wrong at the configuration stage. It's easier for people to help if you provide some specifics about the spaceship and/or the error.