## apgsearch v3.1

For general discussion about Conway's Game of Life.
drc
Posts: 1664
Joined: December 3rd, 2015, 4:11 pm
Location: creating useless things in OCA

### Re: apgsearch v3.1

muzik wrote:Is B3458/S05678 searchable? Running hauls of 5000 and 10000 give an output implying the connection with catagolue was successful, but no new soups appear on the actual site, and 20000 soups gets me a segmentation fault core dumped.
The hauls are probably too big, considering the type of soups that get generated:

Code: Select all

x = 16, y = 16, rule = B3458/S05678
2bob2obo4bobo$o2bobo4bo2bobo$3bobo4bob4o$o2b4o4b2o2bo$o7b7o$o6bob2o4bo$o2bo3b3ob5o$6obobob2o$2bob2o5bob2o$b2o2bob2ob5o$b2o5bob6o$o3bob6obo$
3bo2bo6b3o$o2b5ob5obo$3bobo3bobo$ob2obobobo2bob2o!  \100\97\110\105 muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 I love the way it grows though. Reminds me of the sodium acetate hot ice demonstration, or some weird sort of cancerous growth. Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! Apple Bottom Posts: 1033 Joined: July 27th, 2015, 2:06 pm Contact: ### Re: apgsearch v3.1 muzik wrote:Is B3458/S05678 searchable? No. If you speak, your speech must be better than your silence would have been. — Arabian proverb Catagolue: Apple Bottom • Life Wiki: Apple Bottom • Twitter: @_AppleBottom_ Proud member of the Pattern Raiders! drc Posts: 1664 Joined: December 3rd, 2015, 4:11 pm Location: creating useless things in OCA ### Re: apgsearch v3.1 Apple Bottom wrote: muzik wrote:Is B3458/S05678 searchable? No. The sun is a deadly laser. Does apgmera work with siderakes better than apgsearch v1.0? I keep waking up to my computer frozen because of a siderake occurring in B2-ac3i4a/S12/D4_+2 \100\97\110\105 muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 How many outer-totalistic rules are apgsearchable? Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! Apple Bottom Posts: 1033 Joined: July 27th, 2015, 2:06 pm Contact: ### Re: apgsearch v3.1 drc wrote:Does apgmera work with siderakes better than apgsearch v1.0? I keep waking up to my computer frozen because of a siderake occurring in B2-ac3i4a/S12/D4_+2 apgmera doesn't support non-totalistic rules at all. You're stuck with Aidan's hacked apgsearch for that rule. muzik wrote:How many outer-totalistic rules are apgsearchable? There's no a priori way of telling exactly how a certain rule will behave, short of trying to actually searching or otherwise investigating it (though broad statements about different segments of the rulespace are of course possible), so the answer is really "we don't know". Side note -- slow down cowboy! Please don't overdo it with the new rules. If you keep searching more and more new rules so fast that they'll scroll off the Catagolue frontpage before I have a chance to see them, I'll not be able to record them for the list of rules investigated on Catagolue. (Worse, I might miss other new rules searched by other people such as drc and Rhombic.) Please try and make sure that there's always at least a day's worth of rules in the "Recently updated" section of the Catagolue frontpage. Otherwise it'll be up to YOU to communicate to me the rules that were searched by you AND others that I may have missed. If you speak, your speech must be better than your silence would have been. — Arabian proverb Catagolue: Apple Bottom • Life Wiki: Apple Bottom • Twitter: @_AppleBottom_ Proud member of the Pattern Raiders! muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 I suppose I could keep some screenshots of the page, if any get scrolled off. Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! drc Posts: 1664 Joined: December 3rd, 2015, 4:11 pm Location: creating useless things in OCA ### Re: apgsearch v3.1 Apple Bottom wrote: drc wrote:Does apgmera work with siderakes better than apgsearch v1.0? I keep waking up to my computer frozen because of a siderake occurring in B2-ac3i4a/S12/D4_+2 apgmera doesn't support non-totalistic rules at all. You're stuck with Aidan's hacked apgsearch for that rule. I meant siderakes in general, not nt rules. \100\97\110\105 Apple Bottom Posts: 1033 Joined: July 27th, 2015, 2:06 pm Contact: ### Re: apgsearch v3.1 muzik wrote:I suppose I could keep some screenshots of the page, if any get scrolled off. Please save the HTML file instead, that'll make it easier. Thanks. drc wrote:I meant siderakes in general, not nt rules. In that case, I don't know (but my money's on "no"). If you speak, your speech must be better than your silence would have been. — Arabian proverb Catagolue: Apple Bottom • Life Wiki: Apple Bottom • Twitter: @_AppleBottom_ Proud member of the Pattern Raiders! muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 Will apgsearch and Catagolue ever be able to support B0 rules, non-isotopic rules, Generations rules or Larger than Life rules? Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! calcyman Posts: 2204 Joined: June 1st, 2009, 4:32 pm ### Re: apgsearch v3.1 muzik wrote:Will apgsearch and Catagolue ever be able to support B0 rules, non-isotopic rules, Generations rules or Larger than Life rules? Coincidentally, I've been working on apgmera v4.0 this evening; B0 and LtL will hopefully be in the next release. Isotropic non-totalistic rules might also be possible with much more work. More fundamentally, it uses HashLife for everything. What do you do with ill crystallographers? Take them to the mono-clinic! drc Posts: 1664 Joined: December 3rd, 2015, 4:11 pm Location: creating useless things in OCA ### Re: apgsearch v3.1 calcyman wrote: muzik wrote:Will apgsearch and Catagolue ever be able to support B0 rules, non-isotopic rules, Generations rules or Larger than Life rules? Coincidentally, I've been working on apgmera v4.0 this evening; B0 and LtL will hopefully be in the next release. Isotropic non-totalistic rules might also be possible with much more work. More fundamentally, it uses HashLife for everything. H Y P E Seriously, though, this sounds really cool. I'm assuming LtLs with more than 2 states (on,off) aren't allowed? \100\97\110\105 muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 drc wrote: H Y P E Seriously, though, this sounds really cool. I'm assuming LtLs with more than 2 states (on,off) aren't allowed? Well, if he could support those, generations would also be supported. If he isn't going to be adding generations to 4.0, I doubt it. Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 How many objects have I contributed so far and how close am I to getting a 10^12 badge? Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! calcyman Posts: 2204 Joined: June 1st, 2009, 4:32 pm ### Re: apgsearch v3.1 muzik wrote:How many objects have I contributed so far and how close am I to getting a 10^12 badge? 603948125231 and 60.3948125231%, respectively. What do you do with ill crystallographers? Take them to the mono-clinic! muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 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.? Also, assuming you've tested it so far, how fast does apg4.0 average on B3/S23? How about B3/S? Also, will apgsearch ever support hexagonal and Von Neumann neighbourhoods? Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! toroidalet Posts: 1084 Joined: August 7th, 2016, 1:48 pm Location: My computer Contact: ### Re: apgsearch v3.1 muzik wrote:Will apgsearch ever support hexagonal and Von Neumann neighbourhoods? No need. Hexagonal rules are a subset of MAP rules. Von Neumann neighborhood rules are a subset of MAP rules as well. Support of MAP rules (which I think exists) implies all these things. "Build a man a fire and he'll be warm for a day. Set a man on fire and he'll be warm for the rest of his life." -Terry Pratchett muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 toroidalet wrote:Von Neumann neighborhood rules are a subset of MAP rules as well. Not neccesarily, more like non-totalistic. Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! AforAmpere Posts: 1111 Joined: July 1st, 2016, 3:58 pm ### Re: apgsearch v3.1 Actually, Von Neumann rules can be run now. B2/S23V is B2ei/S2ei3e, for an example. EDIT, I posted at the exact same time as muzik, because I pushed submit, and his post appeared above mine, but still in the preview window, and I had to push it again. Last edited by AforAmpere on August 4th, 2017, 5:30 pm, edited 1 time in total. Wildmyron and I manage the 5S project, which collects all known spaceship speeds in Isotropic Non-totalistic rules. Things to work on: - Find a (7,1)c/8 ship in a Non-totalistic rule muzik Posts: 3787 Joined: January 28th, 2016, 2:47 pm Location: Scotland ### Re: apgsearch v3.1 I wonder, would Catagolue treat them as separate rules? Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace! calcyman Posts: 2204 Joined: June 1st, 2009, 4:32 pm ### Re: apgsearch v3.1 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: Code: Select all x[spq][0-9]+(_[0-9a-z]+)* 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. What do you do with ill crystallographers? Take them to the mono-clinic! Saka Posts: 3436 Joined: June 19th, 2015, 8:50 pm Location: In the kingdom of Sultan Hamengkubuwono X Contact: ### Re: apgsearch v3.1 Calcyman, could we possibly search larger (say 64x64, but 32x32 is enough) soups for LTL rules? I have some good rules but unfortunately 16x16 soups are a bit small and don't really make objects. I'm not interested in symmetry either. Code: Select all o3b2ob2obo3b2o2b2o$bo3b2obob3o3bo2bo$2bo2b3o5b3ob4o$3o3bo2bo2b3o3b3o$4bo4bobo4bo$2o2b2o2b4obo2bo3bo$2ob4o3bo2bo2bo2bo$b2o3bobob2o$3bobobo5b obobobo$3bobobob2o3bo2bobo!

(Check gen 3)

muzik
Posts: 3787
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

### Re: apgsearch v3.1

I know that "z" is an antiquated and unused pattern category, but whenever and wherever it does come up, can it be moved alongside the correct "zz" under Unusual growth?

http://catagolue.appspot.com/census/b2c ... iq67/D2_+1
Bored of using the Moore neighbourhood for everything? Introducing the Range-2 von Neumann isotropic non-totalistic rulespace!

Apple Bottom
Posts: 1033
Joined: July 27th, 2015, 2:06 pm
Contact:

### Re: apgsearch v3.1

A rather different question -- since Catagolue now supports 4x64, 2x128 and 1x256 out of the box, I wondered if I'd be able to adapt apgmera 3.28 to search these.

I almost got it working, but not quite. After reading through the code to gain a superficial and very limited understanding of vlife, I was able to modify <tt>includes/hashsoup.h</tt> as follows:

Code: Select all

--- apgmera-cffe/includes/hashsoup.h    2016-04-01 22:45:45.000000000 +0200
+++ playingaround-cffe/includes/hashsoup.h      2017-08-10 01:19:03.541271800 +0200
@@ -85,6 +85,16 @@
sqt->d[(ROWS / 2) + j - 4] = (digest[4*j+2] << 22) + (digest[4*j+3] << 14);
sqt2->d[(ROWS / 2) + j - 4] = (digest[4*j+1] << 2) + (digest[4*j] << 10);
}
+        } else if (symmetry == "AB_4x64_Test") {
+            VersaTile* sqt3 = &(imp->tiles[std::make_pair(1, 0)]);
+            sqt3->updateflags = 288;
+            sqt->updateflags = 292;
+            for (int j = 0; j < 4; j++) {
+                sqt2->d[(ROWS / 2) + j - 2] = (digest[8*j] << 12) + (digest[8*j+1] << 4) + ((digest[8*j+2] & 0xc0) >> 4);
+                sqt->d[(ROWS / 2) + j - 2] = ((digest[8*j+2] & 0x3f) << 24) + (digest[8*j+3] << 16) + (digest[8*j+4] << 8) + (digest[8*j+5] & 0xfc);
+                sqt3->d[(ROWS / 2) + j - 2] = ((digest[8*j+5] & 3) << 28) + (digest[8*j+6] << 20) + (digest[8*j+7] << 12);
+            }
+            imp->modified.push_back(sqt3);
} else if (symmetry == "D4_+4") {
for (int j = 0; j < 16; j++) {
sqt->d[(ROWS / 2) + j] = (digest[2*j] << 22) + (digest[2*j+1] << 14);

(ROWS is set to 32 by rule2asm.py, BTW, just like for C1 and 8x32.)

Unfortunately this doesn't give QUITE the same results as Aidan's apgsearch 0.54+0.31i, even when you put in the same seed; most of the numbers are the same, but not all are. Here's the log produced for the seed "abcdef123456" by 0.54+0.31i:

Code: Select all

@VERSION v0.54+0.31i
@MD5 9ee721fdedf4175983cae42b2b741b89
@ROOT abcdef123456
@RULE B3S23
@SYMMETRY 4x64
@NUM_SOUPS 10000
@NUM_OBJECTS 334974

@CENSUS TABLE
xs4_33 103428
xp2_7 97856
xs6_696 56129
xq4_153 26612
xs7_2596 16495
xs5_253 15143
xs6_356 9474
xs8_6996 3312
xs4_252 3193
xs7_25ac 1075
xp2_7e 736
xs12_g8o653z11 542
xp2_318c 227
xs6_25a4 210
xs14_g88m952z121 185
xs8_69ic 80
xs7_178c 44
xs8_25ak8 36
xq4_6frc 32
xs6_39c 26
xp3_co9nas0san9oczgoldlo0oldlogz1047210127401 22
xs14_69bqic 19
xs8_35ac 10
xs6_bd 9
xq4_27dee6 9
xs10_g8o652z01 8
xs8_3pm 7
xs16_g88m996z1221 6
xs9_31ego 6
xs14_g88b96z123 6
xs10_35ako 5
xs9_178ko 4
xs9_25ako 4
xs11_g8o652z11 3
xs20_3lkkl3z32w23 2
xs14_j1u066z11 2
xs12_raar 2
xs9_4aar 2
xs16_69egmiczx1 2
xs10_32qr 1
xs10_3215ac 1
xq4_27deee6 1
xs17_3lk453z1243 1
xs12_330fho 1
xs10_3542ac 1
yl384_1_59_7aeb1999980c43b4945fb7fcdb023326 1
xs8_178k8 1
xs11_69lic 1
xs9_312453 1
xs8_312ko 1

@TOP 100
1882 17
9581 16
6845 12
1542 8
8072 8
7597 8
9617 8
1815 8
7835 8
8606 8
3739 8
8493 8
5809 8
8885 8
5948 8
9284 8
7624 8
5450 8
5067 8
205 8
7119 8
2007 8
8411 8
2396 8
9691 8
2015 8
4717 8
5473 8
8803 8
8420 8
9585 8
9592 8
171 7
7305 6
8855 6
414 6
5017 6
3159 6
5978 6
671 6
3233 6
8013 6
8743 6
3420 6
6191 6
7689 6
2105 6
4576 6
6210 6
3141 6
7750 6
5049 6
7075 6
9172 6
5078 6
5608 6
6759 6
5915 6
7655 6
4462 6
9576 6
8304 6
629 6
1910 6
7929 6
914 4
719 4
2071 4
7537 4
9000 3
4411 3
8782 3
444 1
172 1
5847 1
297 1
8687 1

@SAMPLE_SOUPIDS
xs4_33 79 79 75 75 80 80 50 50 41 41
xp2_7 1882 1882
xs6_696 36 36 30 28 1 1 109 300 182 358
xs7_2596 76 74 78 76 72 75 74 80 80 79
xs5_253 79 79 78 80 78 76 76 80 70 68
xs6_356 78 77 74 80 79 69 70 69 64 68
xs8_6996 69 69 70 52 47 46 51 42 40 43
xs4_252 74 78 80 63 68 51 46 51 51 51
xs7_25ac 72 61 55 52 42 43 43 81 88 99
xp2_7e 68 37 1 1 103 135 150 172 149 133
xs12_g8o653z11 70 55 55 42 16 16 13 8 116 116
xp2_318c 58 50 51 208 255 287 229 229 216 329
xs6_25a4 118 105 217 271 223 221 322 382 435 474
xs14_g88m952z121 131 121 121 114 114 283 283 343 343 558
xs8_69ic 172 466 598 625 713 1229 1316 1503 1514 1626
xs7_178c 51 19 233 423 468 551 973 1105 1223 1519
xs8_25ak8 460 435 779 1105 1441 2256 3064 3162 3174 3277
xq4_6frc 414 671 629 1910 2105 3159 3141 3233 3420 4462
xs6_39c 410 880 1105 1847 2207 2426 2930 5037 5558 5695
xp3_co9nas0san9oczgoldlo0oldlogz1047210127401 1815 2015 2007 2396 4717 5067 5473 5450 7119 7624
xs14_69bqic 16 653 1498 1739 3097 3552 4045 4060 4126 4981
xs8_35ac 2807 3642 3953 5320 6598 7295 7636 7894 9548 9685
xs6_bd 1600 1946 2809 4077 4824 5765 6506 7700 8020
xq4_27dee6 205 1542 3739 5809 5948 7597 8072 9581 9581
xs10_g8o652z01 828 1587 1764 2648 2648 7059 7059 8392
xs8_3pm 1688 3993 5008 5508 6137 6297 8685
xs16_g88m996z1221 682 4056 5027 5711 6056 7024
xs9_31ego 2089 2085 4609 6549 7014 8211
xs14_g88b96z123 3228 3208 3471 7526 7707 9266
xs10_35ako 3161 3381 4145 5691 9813
xs9_178ko 4294 6946 7202 8743
xs9_25ako 52 1749 3584 9050
xs11_g8o652z11 817 1659 5885
xs20_3lkkl3z32w23 4411 8782
xs14_j1u066z11 297 8687
xs12_raar 6478 9696
xs9_4aar 776 2826
xs16_69egmiczx1 172 444
xs10_32qr 5847
xs10_3215ac 7537
xq4_27deee6 6845
xs17_3lk453z1243 171
xs12_330fho 9000
xs10_3542ac 914
yl384_1_59_7aeb1999980c43b4945fb7fcdb023326 1882
xs8_178k8 3176
xs11_69lic 2071
xs9_312453 719
xs8_312ko 6000

And here's the log produced for the same seed by the modified apgmera 3.1:

Code: Select all

@VERSION v3.28
@MD5 9ee721fdedf4175983cae42b2b741b89
@ROOT abcdef123456
@RULE b3s23
@SYMMETRY AB_4x64_Test
@NUM_SOUPS 10000
@NUM_OBJECTS 335180

@CENSUS TABLE
xs4_33 103479
xp2_7 97919
xs6_696 56168
xq4_153 26615
xs7_2596 16511
xs5_253 15160
xs6_356 9491
xs8_6996 3312
xs4_252 3193
xs7_25ac 1075
xp2_7e 736
xs12_g8o653z11 542
xp2_318c 227
xs6_25a4 210
xs14_g88m952z121 185
xs8_69ic 80
xs7_178c 44
xs8_25ak8 36
xq4_6frc 32
xs6_39c 26
xp3_co9nas0san9oczgoldlo0oldlogz1047210127401 22
xs14_69bqic 19
xs8_35ac 10
xs6_bd 9
xq4_27dee6 9
xs10_g8o652z01 8
xs8_3pm 7
xs9_31ego 6
xs16_g88m996z1221 6
xs14_g88b96z123 6
xs10_35ako 5
xs9_25ako 4
xs9_178ko 4
xs11_g8o652z11 3
xs9_4aar 2
xs20_3lkkl3z32w23 2
xs16_69egmiczx1 2
xs14_j1u066z11 2
xs12_raar 2
yl384_1_59_7aeb1999980c43b4945fb7fcdb023326 1
xs9_312453 1
xs8_312ko 1
xs8_178k8 1
xs17_3lk453z1243 1
xs12_330fho 1
xs11_69lic 1
xs10_3542ac 1
xs10_32qr 1
xs10_3215ac 1
xq4_27deee6 1

@SAMPLE_SOUPIDS
xs4_33 0 1 2 3 5 7 8 10 11 12
xp2_7 0 1 3 5 7 8 11 15 16 17
xs6_696 1 3 4 5 7 8 9 10 11 12
xq4_153 1393 1420 1783 2979 8238
xs7_2596 0 1 5 7 8 9 10 11 13 14
xs5_253 20 36 190 216 223 229 264 287 305 392
xs6_356 0 1 2 6 7 9 10 11 12 13
xs8_6996 2 8 10 11 15 16 17 20 26 40
xs4_252 1 4 7 11 15 16 17 18 23 24
xs7_25ac 42 43 52 55 61 72 81 88 99 114
xp2_7e 1 37 68 103 118 133 135 140 149 150
xs12_g8o653z11 8 13 16 42 55 70 116 150 182 195
xp2_318c 50 51 58 208 216 229 255 287 329 358
xs6_25a4 105 118 217 221 223 271 322 382 435 474
xs14_g88m952z121 114 121 131 283 343 558 570 573 659 729
xs8_69ic 172 466 598 625 713 1229 1316 1503 1514 1626
xs7_178c 19 51 233 423 468 551 973 1105 1223 1519
xs8_25ak8 435 460 779 1105 1441 2256 3064 3162 3174 3277
xq4_6frc 414 629 671 1910 2105 3141 3159 3233 3420 4462
xs6_39c 410 880 1105 1847 2207 2426 2930 5037 5558 5695
xp3_co9nas0san9oczgoldlo0oldlogz1047210127401 1815 2007 2015 2396 4717 5067 5450 5473 7119 7624
xs14_69bqic 16 653 1498 1739 3097 3552 4045 4060 4126 4981
xs8_35ac 2807 3642 3953 5320 6598 7295 7636 7894 9548 9685
xs6_bd 1600 1946 2809 4077 4824 5765 6506 7700 8020
xq4_27dee6 205 1542 3739 5809 5948 7597 8072 9581
xs10_g8o652z01 828 1587 1764 2648 7059 8392
xs8_3pm 1688 3993 5008 5508 6137 6297 8685
xs9_31ego 2085 2089 4609 6549 7014 8211
xs16_g88m996z1221 682 4056 5027 5711 6056 7024
xs14_g88b96z123 3208 3228 3471 7526 7707 9266
xs10_35ako 3161 3381 4145 5691 9813
xs9_25ako 52 1749 3584 9050
xs9_178ko 4294 6946 7202 8743
xs11_g8o652z11 817 1659 5885
xs9_4aar 776 2826
xs20_3lkkl3z32w23 4411 8782
xs16_69egmiczx1 172 444
xs14_j1u066z11 297 8687
xs12_raar 6478 9696
yl384_1_59_7aeb1999980c43b4945fb7fcdb023326 1882
xs9_312453 719
xs8_312ko 6000
xs8_178k8 3176
xs17_3lk453z1243 171
xs12_330fho 9000
xs11_69lic 2071
xs10_3542ac 914
xs10_32qr 5847
xs10_3215ac 7537
xq4_27deee6 6845

Note how the most common objects -- xs4_33, xp2_7, xs6_696, xq4_153, xs7_2596, xs5_253 and xs6_356 -- are all slightly more common in apgmera 3.28.

I don't know what this is due to. I don't see anything wrong with my hashsoup modification -- outputting the soup constructed matches what the server says the soup should be (e.g. this) anyway --, but for obvious reasons I don't want to start submitting results that aren't compatible with other versions of the script.

So, does anyone have any ideas why the results don't QUITE match up?

SIDE NOTE: I did manage to accidentally submit a single haul with incorrect data to 4x64 earlier tonight, too. I've asked Calcyman to back it out of the census -- until it's gone, please take the census results there with a grain of salt, and ignore the supposed PATHOLOGICALs.

EDIT:the incorrect haul in 4x64 was backed out of the census (thanks Calcyman!), and I've learned a lesson about not using non-testing symmetries, even when I believe nothing will get submitted to Catagolue.
Last edited by Apple Bottom on August 10th, 2017, 5:51 am, edited 1 time in total.
If you speak, your speech must be better than your silence would have been. — Arabian proverb

Catagolue: Apple Bottom • Life Wiki: Apple Bottom • Twitter: @_AppleBottom_

Proud member of the Pattern Raiders!

A for awesome
Posts: 2051
Joined: September 13th, 2014, 5:36 pm
Location: 0x-1
Contact:

### Re: apgsearch v3.1

Apple Bottom wrote:So, does anyone have any ideas why the results don't QUITE match up?
Maybe the glider-producing switch engine? The Python and C++ versions might run the offending soups for different periods of time, resulting in different quantities of debris, consisting of the most common Life objects, which are indeed the ones that show discrepancies.

Maybe try the test again with a different seed that doesn't produce any switch engines, and see if that accounts for it.
x₁=ηx
V ⃰_η=c²√(Λη)
K=(Λu²)/2
Pₐ=1−1/(∫^∞_t₀(p(t)ˡ⁽ᵗ⁾)dt)

$$x_1=\eta x$$
$$V^*_\eta=c^2\sqrt{\Lambda\eta}$$
$$K=\frac{\Lambda u^2}2$$
$$P_a=1-\frac1{\int^\infty_{t_0}p(t)^{l(t)}dt}$$

http://conwaylife.com/wiki/A_for_all

Aidan F. Pierce