apgsearch v4.0

[muzik]

I imagine that you're calling apgmera (4.15) which realises that the rules don't match, so it calls recompile.sh and builds apgluxe (4.2) which is subsequently called.

If my suspicion is correct, you'll get 4.15 for exactly one rule/symmetry and 4.2 for everything else.

This definitely seems to be the thing that's happening. The lists of hauls also reads the version as 1.15 as well.

[praosylen]

Also, pseudo-object separation is not working properly: https://catagolue.appspot.com/haul/b3s2 ... 3f5b110bf4

[Apple Bottom]

Apologies for the double-post, but v4.2 now supports non-totalistic isotropic rules.

Excellent!

Judging by the haul timestamps for b37s2-i34q/C1, it appears to be roughly 3 or 4 times faster than the Golly Python version.

This appears to be rule-dependent -- in fact for some rules Golly/Python/apgsearch 0.x is faster, at least for me.

For B2cek4ejt5aj6c/S123a5i, apgluxe 4.2-ll1.2 achieved a throughput of around 140 soups/second. apgsearch 0.54+0.33i (Aidan't latest) is currently at an overall speed of 164 soups/second. I let both versions run for several million soups.

EDIT: having trouble with B2e3ai4arw5678/S3-an4ar5i678 as well. The searcher ran normally for the first ~30 seconds, but then stopped printing status messages:

Code: Select all

Greetings, this is apgluxe v4.2-ll1.2, configured for b2e3ai4arw5678s3-an4ar5i678/C1.

Lifelib version: ll1.2
Compiler version: 6.3.0
Python version: '2.7.13 (default, Mar 13 2017, 20:56:15)  [GCC 5.4.0]'

Using seed l_6FAAv4uqrTwD
Computing 2^18-entry lookup table...done!
Computing 2^24-entry lookup table...done!
Computing 2^18-entry mixing table...done!
Running 1000000 soups per haul:
Pathological object detected!!!
Pathological object detected!!!
Chaotic-growth pattern detected: zz_EXPLOSIVE
Chaotic-growth pattern detected: zz_EXPLOSIVE
Linear-growth pattern detected: yl5_1_12_e9bbac9b9846d3dea87ce05747612167
b2e3ai4arw5678s3-an4ar5i678/C1: 324 soups completed (30.59 soups/second current, 30.59 overall).
Linear-growth pattern detected: yl10_1_20_97ea763509606dfdfbb37cadb0a7a3bb
Linear-growth pattern detected: yl70_1_154_d318e653f629e19bd4405b01e73b30fa
Linear-growth pattern detected: yl40_1_64_9d05869e5d8ce330f50cdb1195d95a1c
b2e3ai4arw5678s3-an4ar5i678/C1: 483 soups completed (12.60 soups/second current, 20.81 overall).
Linear-growth pattern detected: yl5_1_12_e9bbac9b9846d3dea87ce05747612167
Linear-growth pattern detected: yl10_1_18_9674a2002734cbb22c757d40a957cf27
Pathological object detected!!!
Linear-growth pattern detected: yl10_1_28_98e7fc1396301ae1daab62dc86ecd310
b2e3ai4arw5678s3-an4ar5i678/C1: 776 soups completed (21.06 soups/second current, 20.90 overall).
Linear-growth pattern detected: yl10_1_20_97ea763509606dfdfbb37cadb0a7a3bb
Linear-growth pattern detected: yl10_1_18_9674a2002734cbb22c757d40a957cf27

I killed it after ~10 hours; total memory consumption at the time was ~11.5 GB.

[drc]

More phantom objects are being reported, what is happening? This should be affecting other rules too I think-

[Rhombic]

More phantom objects are being reported, what is happening? This should be affecting other rules too I think-

This seems an important issue.


Side suggestion:
When apgluxe returns
Failed to detect periodic behaviour!
it should probably skip the soup. Or something like that, alternatively. At the moment apgluxe (for me, at least) ceases to search more, which probably means it's just evolving that aperiodic explosive soup.

[muzik]

Side suggestion:
When apgluxe returns
Failed to detect periodic behaviour!
it should probably skip the soup. Or something like that, alternatively. At the moment apgluxe (for me, at least) ceases to search more, which probably means it's just evolving that aperiodic explosive soup.

I think that message appears when an extremely high-period object shows up that apgsearch cant classify, not an exploding soup. From my massive-finger typos resulting in searching explosive rules it seems that apgsearch just gives up entirely producing no errors.


On another topic: I wonder what's coming next to apgsearch.

[calcyman]

Failed to detect periodic behaviour!

I think that message appears when an extremely high-period object shows up that apgsearch cant classify, not an exploding soup. From my massive-finger typos resulting in searching explosive rules it seems that apgsearch just gives up entirely producing no errors.

Even if it fails to detect periodic behaviour, it might correctly classify certain high-period oscillators. In particular, it only attempts to run soups for about 120000 generations, but can detect individual objects with periods up to 2^20:

https://catagolue.appspot.com/object/xp ... izf/b026s1

...which is unfortunately just a disjoint union of a p2864 and a p724. (I think B0 rules don't bother invoking ppbosc() to separate pseudo-oscillators; otherwise, it would take considerably longer to search.)

Edit: muzik, seriously? Is there really any point searching this rule? https://catagolue.appspot.com/object/ov ... 24s113t225

[Saka]

On another topic: I wonder what's coming next to apgsearch.

Non-totalistic generations?

[muzik]

Edit: muzik, seriously? Is there really any point searching this rule? https://catagolue.appspot.com/object/ov ... 24s113t225

Well I do want there to be a record of every rule which has an officially recognised name.

On another topic: I wonder what's coming next to apgsearch.

Non-totalistic generations?

Seems like a valid next step. The other two main ones I can think of would be B0 non-totalistic and LTL Generations.

[drc]

Apgsearch v4.0 seems to have frozen up, how can I tell what current soup it's on? It's on a non-explosive rule/symmetry, b2-ac3i4as12/D8_1.

EDIT: This happened in haul l_YgxgVTdymhXD , at some soup between 182968-200000

[calcyman]

On another topic: I wonder what's coming next to apgsearch.

Non-totalistic generations?

Seems like a valid next step. The other two main ones I can think of would be B0 non-totalistic and LTL Generations.

In terms of further rule families, the next one I intend to implement is outer-totalistic rules up to range 5.

[muzik]

Sounds riveting! How would they be notated though?

[Saka]

In terms of further rule families, the next one I intend to implement is outer-totalistic rules up to range 5.

Outer totalistic? What's that mean?

[Apple Bottom]

Outer totalistic? What's that mean?

In an outer-totalistic CA, the state of a given cell in the next generation depends only on the cell's own state and the total number of live cells in the cell's neighborhood.

It's called "totalistic" because only the total number of live cells is considered, not their alignment, and "outer-totalistic" because the live cells thus considered are the "outer" cells, i.e. those not identical to the center cell itself, which may be considered separately. (Obviously including the center cell in the count of live cells yields an equivalent definition, so long as that cell's state is still considered individually.)

"Semi-totalistic" is a synonym for "outer-totalistic", BTW. And "totalistic" is sometimes used instead, but strictly speaking that's a smaller class of CAs that excludes e.g. Conway Life.

[Saka]

In an outer-totalistic CA, the state of a given cell in the next generation depends only on the cell's own state and the total number of live cells in the cell's neighborhood...

Hmm, I still dont get it, so basically just like LTL but with specific birth/survivals and not the "..." thing, right?

[Apple Bottom]

Hmm, I still dont get it, so basically just like LTL but with specific birth/survivals and not the "..." thing, right?

Larger than Life rules (as defined on the wiki) are all outer-totalistic (so far as I can tell). If the middle cell is included in the neighborhood count (M1), they're actually totalistic as well, but of course all totalistic rules are also outer-totalistic.

I couldn't speculate on what Calcyman's planning, but so far all LtL rules that apgluxe supports are totalistic (M1), so my best guess is that he's working on also supporting those that aren't (M0).

(Side note: depending on the context, "outer-totalistic" may tacitly imply "Life-like". Obviously that's not the case here, but if you see outer-totalistic rules being talked about elsewhere, it might just be the usual B.../S... rules, like B3/S23, B3678/S34678, etc.)

[calcyman]

Hmm, I still dont get it, so basically just like LTL but with specific birth/survivals and not the "..." thing, right?

Larger than Life rules (as defined on the wiki) are all outer-totalistic (so far as I can tell). If the middle cell is included in the neighborhood count (M1), they're actually totalistic as well, but of course all totalistic rules are also outer-totalistic.

I couldn't speculate on what Calcyman's planning, but so far all LtL rules that apgluxe supports are totalistic (M1), so my best guess is that he's working on also supporting those that aren't (M0).

(Side note: depending on the context, "outer-totalistic" may tacitly imply "Life-like". Obviously that's not the case here, but if you see outer-totalistic rules being talked about elsewhere, it might just be the usual B.../S... rules, like B3/S23, B3678/S34678, etc.)

The M0/M1 is just a notational convenience; for an 'M0' rule, increment all of the survivals to turn it into an equivalent 'M1' rule, and vice-versa.

I meant specific birth/survivals, as Saka said -- so your B/S rules needn't be intervals. B38/S23, for instance, is outer-totalistic but not LtL.

[muzik]

It still excites me that apgsearch will be able to search a family of rules that even golly can't even simulate yet (unless ruletables support larger neighbourhoods).

[Apple Bottom]

The M0/M1 is just a notational convenience; for an 'M0' rule, increment all of the survivals to turn it into an equivalent 'M1' rule, and vice-versa.

Oh, yes; you're right, of course. D'oh, that really should've been obvious to me.

[M. I. Wright]

Code: Select all

./apgluxe -n 20000000

Greetings, this is apgluxe v4.2-ll1.2, configured for b3s23/C1.

Lifelib version: ll1.2
Compiler version: 6.3.0 20170406
Python version: '2.7.13 (default, Jan 19 2017, 14:48:08)  [GCC 6.3.0 20170118]'

Peer-reviewing hauls:

Illegal instruction (core dumped)

Ubuntu 17.04 Where does it dump to and/or where should I go from here?

[calcyman]

Code: Select all

Illegal instruction (core dumped)

Ubuntu 17.04 Where does it dump to and/or where should I go from here?

The most useful information would be to post the contents of cat /proc/cpuinfo. I'd expect to see this error if you're not on a x86-64 architecture (e.g. ARM or a 32-bit i386 architecture).

As for where core dumps are stored, that's a different story. It used to be the case that they were dumped into the working directory, even if you don't have write permissions; this was later exploited to run arbitrary code as root (by writing a broken program and calling it from cron.d, then waiting...).

[M. I. Wright]

Alright! (uname -m does show x86_64, for the record):

Code: Select all

$ cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 6
model name	: AMD Phenom(tm) II X2 511 Processor
stepping	: 3
microcode	: 0x10000c8
cpu MHz		: 800.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs		: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
bogomips	: 6783.67
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 6
model name	: AMD Phenom(tm) II X2 511 Processor
stepping	: 3
microcode	: 0x10000c8
cpu MHz		: 800.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs		: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
bogomips	: 6783.67
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

[calcyman]

You have both SSE and SSE2, so it should be able to run outer-totalistic rules without any problems. Unless I've accidentally used an instruction from a higher instruction set without noticing.

[Rocknlol]

Catagolue seems to be returning incorrect sample soups for B0 rules with C2_2 symmetry.

Some examples of this are here, here, and here.

[M. I. Wright]

You have both SSE and SSE2, so it should be able to run outer-totalistic rules without any problems. Unless...

Apparently not Thank you for checking though!