Re: Hacking apgsearch
Posted: January 25th, 2016, 10:29 pm
Just uploaded a haul of B3S23-q, hope it worked!
Edit: woo hoo!
Edit: woo hoo!
Code: Select all
---------------------------
Golly warning:
---------------------------
Error reading APG_CoalesceObjects_B2-aS12.rule on line 87: ba,bb,bc,2 - too few entries
---------------------------
OK
---------------------------
Code: Select all
@RULE B2-aS12
@TABLE
n_states:2
neighborhood:Moore
symmetries:rotate4reflect
0,1,0,1,0,0,0,0,0,1
0,1,0,0,1,0,0,0,0,1
0,1,0,0,0,1,0,0,0,1
0,0,1,0,1,0,0,0,0,1
0,0,1,0,0,1,0,0,0,1
0,0,1,0,0,0,1,0,0,1
1,0,0,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,0,1,0,0,0,0,0
1,1,1,0,0,1,0,0,0,0
1,1,1,0,0,0,1,0,0,0
1,1,1,0,0,0,0,1,0,0
1,1,1,0,0,0,0,0,1,0
1,1,0,1,0,1,0,0,0,0
1,1,0,1,0,0,1,0,0,0
1,1,0,0,1,0,1,0,0,0
1,0,1,0,1,0,1,0,0,0
1,1,1,1,1,0,0,0,0,0
1,1,1,1,0,1,0,0,0,0
1,1,1,1,0,0,1,0,0,0
1,1,1,0,1,1,0,0,0,0
1,1,1,0,1,0,1,0,0,0
1,1,1,0,1,0,0,1,0,0
1,1,1,0,1,0,0,0,1,0
1,1,1,0,0,1,1,0,0,0
1,1,1,0,0,1,0,1,0,0
1,1,1,0,0,1,0,0,1,0
1,1,1,0,0,0,1,1,0,0
1,1,0,1,0,1,0,1,0,0
1,0,1,0,1,0,1,0,1,0
1,0,0,0,1,1,1,1,1,0
1,0,0,1,0,1,1,1,1,0
1,0,0,1,1,0,1,1,1,0
1,0,0,1,1,1,0,1,1,0
1,0,0,1,1,1,1,0,1,0
1,0,0,1,1,1,1,1,0,0
1,0,1,0,1,0,1,1,1,0
1,0,1,0,1,1,0,1,1,0
1,0,1,1,0,1,0,1,1,0
1,1,0,1,0,1,0,1,1,0
1,0,0,1,1,1,1,1,1,0
1,0,1,0,1,1,1,1,1,0
1,0,1,1,0,1,1,1,1,0
1,0,1,1,1,0,1,1,1,0
1,1,0,1,0,1,1,1,1,0
1,1,0,1,1,1,0,1,1,0
1,0,1,1,1,1,1,1,1,0
1,1,0,1,1,1,1,1,1,0
1,1,1,1,1,1,1,1,1,0
@COLORS
0 0 0 0
1 255 255 255
It's the @COLORS section; I will fix this in the next update, but for now, just put an amended version of the rule without the @COLORS section in Golly's rules folder (keeping the version including the colors in your rules folder). This takes advantage of the fact that Golly and apgsearch look up rules in the opposite order from each other, so Golly sees the colors and apgsearch doesn't.drc wrote:I keep getting the error:
When I use a new rule with both 0.2i and 0.21i. What is happening? An example of a used rule:Code: Select all
--------------------------- Golly warning: --------------------------- Error reading APG_CoalesceObjects_B2-aS12.rule on line 87: ba,bb,bc,2 - too few entries --------------------------- OK ---------------------------
Code: Select all
@RULE B2-aS12 @TABLE n_states:2 neighborhood:Moore symmetries:rotate4reflect 0,1,0,1,0,0,0,0,0,1 0,1,0,0,1,0,0,0,0,1 0,1,0,0,0,1,0,0,0,1 0,0,1,0,1,0,0,0,0,1 0,0,1,0,0,1,0,0,0,1 0,0,1,0,0,0,1,0,0,1 1,0,0,0,0,0,0,0,0,0 1,1,1,1,0,0,0,0,0,0 1,1,1,0,1,0,0,0,0,0 1,1,1,0,0,1,0,0,0,0 1,1,1,0,0,0,1,0,0,0 1,1,1,0,0,0,0,1,0,0 1,1,1,0,0,0,0,0,1,0 1,1,0,1,0,1,0,0,0,0 1,1,0,1,0,0,1,0,0,0 1,1,0,0,1,0,1,0,0,0 1,0,1,0,1,0,1,0,0,0 1,1,1,1,1,0,0,0,0,0 1,1,1,1,0,1,0,0,0,0 1,1,1,1,0,0,1,0,0,0 1,1,1,0,1,1,0,0,0,0 1,1,1,0,1,0,1,0,0,0 1,1,1,0,1,0,0,1,0,0 1,1,1,0,1,0,0,0,1,0 1,1,1,0,0,1,1,0,0,0 1,1,1,0,0,1,0,1,0,0 1,1,1,0,0,1,0,0,1,0 1,1,1,0,0,0,1,1,0,0 1,1,0,1,0,1,0,1,0,0 1,0,1,0,1,0,1,0,1,0 1,0,0,0,1,1,1,1,1,0 1,0,0,1,0,1,1,1,1,0 1,0,0,1,1,0,1,1,1,0 1,0,0,1,1,1,0,1,1,0 1,0,0,1,1,1,1,0,1,0 1,0,0,1,1,1,1,1,0,0 1,0,1,0,1,0,1,1,1,0 1,0,1,0,1,1,0,1,1,0 1,0,1,1,0,1,0,1,1,0 1,1,0,1,0,1,0,1,1,0 1,0,0,1,1,1,1,1,1,0 1,0,1,0,1,1,1,1,1,0 1,0,1,1,0,1,1,1,1,0 1,0,1,1,1,0,1,1,1,0 1,1,0,1,0,1,1,1,1,0 1,1,0,1,1,1,0,1,1,0 1,0,1,1,1,1,1,1,1,0 1,1,0,1,1,1,1,1,1,0 1,1,1,1,1,1,1,1,1,0 @COLORS 0 0 0 0 1 255 255 255
I guess v0.2Ni has been outputting the rules in the wrong format all along. Here's the patched script: You are, again, strongly recommended to update. I also updated the Hensel-test.py script in the main v0.2Ni post to reflect the change.dvgrn wrote:the correct "n" instead of the old Life32 "v".
Code: Select all
@RULE B2-aei3-a_S2-i34-i
*** File autogenerated by saverule. ***
This is a two state, isotropic, non-totalistic rule on the Moore neighbourhood.
The notation used to define the rule was originally proposed by Alan Hensel.
See http://www.ibiblio.org/lifepatterns/neighbors2.html for details
@TABLE
n_states:2
neighborhood:Moore
symmetries:rotate4reflect
var a={0,1}
var b={0,1}
var c={0,1}
var d={0,1}
var e={0,1}
var f={0,1}
var g={0,1}
var h={0,1}
# Birth
0,1,0,0,1,0,0,0,0,1
0,0,1,0,1,0,0,0,0,1
0,0,1,0,0,0,1,0,0,1
0,1,1,0,1,0,0,0,0,1
0,1,1,0,0,1,0,0,0,1
0,1,1,0,0,0,1,0,0,1
0,1,1,0,0,0,0,1,0,1
0,1,1,0,0,0,0,0,1,1
0,1,0,1,0,1,0,0,0,1
0,1,0,1,0,0,1,0,0,1
0,1,0,0,1,0,1,0,0,1
0,0,1,0,1,0,1,0,0,1
# Survival
1,1,1,0,0,0,0,0,0,1
1,1,0,1,0,0,0,0,0,1
1,1,0,0,1,0,0,0,0,1
1,0,1,0,1,0,0,0,0,1
1,0,1,0,0,0,1,0,0,1
1,1,1,1,0,0,0,0,0,1
1,1,1,0,1,0,0,0,0,1
1,1,1,0,0,1,0,0,0,1
1,1,1,0,0,0,1,0,0,1
1,1,1,0,0,0,0,1,0,1
1,1,1,0,0,0,0,0,1,1
1,1,0,1,0,1,0,0,0,1
1,1,0,1,0,0,1,0,0,1
1,1,0,0,1,0,1,0,0,1
1,0,1,0,1,0,1,0,0,1
1,1,1,1,1,0,0,0,0,1
1,1,1,1,0,1,0,0,0,1
1,1,1,1,0,0,1,0,0,1
1,1,1,0,1,0,1,0,0,1
1,1,1,0,1,0,0,1,0,1
1,1,1,0,1,0,0,0,1,1
1,1,1,0,0,1,1,0,0,1
1,1,1,0,0,1,0,1,0,1
1,1,1,0,0,1,0,0,1,1
1,1,1,0,0,0,1,1,0,1
1,1,0,1,0,1,0,1,0,1
1,0,1,0,1,0,1,0,1,1
# Death
1,a,b,c,d,e,f,g,h,0
@COLORS
Generally (and I've encountered this a lot), it has to do with the time it takes soups to come to stabilization. For this rule, that time tends to run over 100000 gens. The RuleLoader algorithm naturally runs these patterns slower and takes more memory to do so (thanks to the hashing, which is useless for running soups to stabilization). I've found that 0.54+0.21i chokes up once soups start regularly taking in excess of 20000 gens to stabilize. I see no way to solve this problem, other than to write 0.54+0.21i up into a standalone c++ implementation (which I don't really know how to do) and use a non-hashing algorithm or wait for Golly 3.0 to come out.Apple Bottom wrote:Not so much a bug as a problem: searching certain rules will cause 0.54+0.21i to rapidly consume all available memory and cause the machine it's running on to thrash.
Example rule: B2-aei3-a/S2-i34-i (rule files generated by isotropic-rule.py):Code: Select all
image
I'd make a mostly uneducated guess that this is due to extremely high-period oscillators.Code: Select all
rule
OK, fair enough. The problem's easy to diagnose and fix, so it shouldn't be a problem in practice.A for awesome wrote:Generally (and I've encountered this a lot), it has to do with the time it takes soups to come to stabilization. For this rule, that time tends to run over 100000 gens. The RuleLoader algorithm naturally runs these patterns slower and takes more memory to do so (thanks to the hashing, which is useless for running soups to stabilization). I've found that 0.54+0.21i chokes up once soups start regularly taking in excess of 20000 gens to stabilize. I see no way to solve this problem, other than to write 0.54+0.21i up into a standalone c++ implementation (which I don't really know how to do) and use a non-hashing algorithm or wait for Golly 3.0 to come out.
This seems like it might be a very good idea for non-totalistic rules. I will probably implement some variation of this feature if I ever get around to making 0.22i.Apple Bottom wrote:Still, I'm wondering. Why run the pattern until stabilization no matter how generations it takes, instead of stopping after (say) 20,000? Rules like these aren't really suitable for soup-searching anyway, so perhaps the script could just pop up a message to this effect (possibly allowing the user to continue anyway, if they so choose).
I am mildly embarrassed to say that I don't actually know how to do that. It probably would still run slower than the equivalent outer-totalistic search (due to inherent inefficiencies in the RuleLoader algorithm compared to QuickLife).fluffykitty wrote:What happens if you set the hash memory to 0?
You mean the memory limit for HashLife in Golly's preferences? I'm not sure what that would accomplish, since setting it to 0 would actually remove the limit (set to 500 MB now).fluffykitty wrote:What happens if you set the hash memory to 0?
http://conwaylife.com/forums/viewtopic. ... &start=281Apple Bottom wrote:There's a small issue with chaotic-growth patterns; these are reported as z_* instead of zz_*, e.g. z_QUADRATIC instead of zz_QUADRATIC, as seen here.
The culprit's powerlyse(), which returns the wrong descriptions.
Apple Bottom wrote:There's a small issue with chaotic-growth patterns; these are reported as z_* instead of zz_*, e.g. z_QUADRATIC instead of zz_QUADRATIC, as seen here.
This should be fixed in v(0.54+0.22i).A for awesome wrote:http://conwaylife.com/forums/viewtopic. ... &start=281
I'm actually working on a version of pseudo-bangbang that separates moving objects. I will probably include it in the next version, which would also get rid of things like this.gameoflifeboy wrote:Another thing that should be added is the ability to separate pairs of gliders that only run in non-Life-like rules. See here: http://catagolue.appspot.com/object/xq4 ... b3-kq4js23
Code: Select all
switch (c)
{
case 0:
if (state1 neighbors==8)
return 2;
else if ((state1 neighbors + state6 neighbors ==3 )||(state2 neighbors + state4 neighbors >=1))
return 1;
else
return 0;
case 1 :
if (state1 neighbors==8)
return 2;
else if (
!(
( ( state1 neighbors + state6 neighbors ) | 1 )
==3)
||
(state3 neighbors + state4 neighbors>=1 )
)
return 0;
else
return 1;
case 2:
if ( ( ( state1 neighbors + state2 neighbors) | 1 )==3 )
return 2;
else
return 0;
case 3: return 3;
case 4: return 4;
case 5: return 5;
case 6: return 6;
default:
return 0 ; // should throw an error here
}
Code: Select all
@RULE eelife3
# General Behavior:
#
# 0 is empty
# 1 is on
# 2 is birthforcer
# Specific Behavior
# 0 changes to 2 when state2 neighbors ==8
otherwise changes to 1 when (state1 neighbors==3) || (state2 neighbors>=1)
otherwise 0 stays 0
# 0 or 1 changes to 2 when state1 neighbors == 8
# 1 changes to 0 when (state1 neighbors) != 2, 3
# 2 changes to 0 when (state1 neighbors + state2 neighbors) !=2,3
# changes to 1 when state1 neighbors ==3
# otherwise 1,2 stays 1,2
#
@TABLE
# rules: 52
#
# Golly rule-table format.
# Each rule: C,N,NE,E,SE,S,SW,W,NW,C'
# N.B. Where the same variable appears multiple times in a transition,
# it takes the same value each time.
#
# Default for transitions not listed: no change
#
n_states:4
neighborhood:Moore
symmetries:rotate8
var a={0,1,2,3}
var b={0,1,2,3}
var c={0,1,2,3}
var d={0,1,2,3}
var e={0,1,2,3}
var f={0,1,2,3}
var g={0,1,2,3}
var h={0,3}
var i={0,3}
var j={0,3}
var k={0,3}
var l={0,3}
var m={0,1}
var n={0,2,3}
var o={0,2,3}
var p={0,2,3}
var q={0,2,3}
var r={0,2,3}
var s={0,2,3}
var t={0,2,3}
var u={1,2}
var v={0,3}
var w={0,3}
var x={1,2}
var y={1,2}
var z={1,2}
0,a,b,c,d,e,f,g,2,1
0,h,i,j,k,l,1,1,1,1
0,h,i,j,k,1,l,1,1,1
0,h,i,j,k,1,1,l,1,1
0,h,i,j,1,k,l,1,1,1
0,h,i,j,1,k,1,l,1,1
0,h,i,j,1,1,k,l,1,1
0,h,i,1,j,k,1,l,1,1
m,1,1,1,1,1,1,1,1,2
1,n,o,p,q,r,s,t,a,0
1,a,b,c,d,e,f,g,3,0
1,0,0,0,0,0,1,3,1,0
1,0,0,0,0,0,3,1,1,0
1,0,0,0,0,1,0,1,3,0
1,0,0,0,0,1,0,3,1,0
1,0,0,0,0,1,1,0,3,0
u,n,a,b,c,1,1,1,1,0
1,0,0,0,0,1,3,0,1,0
1,0,0,0,0,3,0,1,1,0
1,0,0,0,0,3,1,0,1,0
u,n,a,b,1,o,1,1,1,0
u,n,a,b,1,1,o,1,1,0
u,n,o,p,1,1,1,q,1,0
u,n,o,1,p,q,1,1,1,0
u,n,o,1,p,1,q,1,1,0
u,n,o,1,p,1,1,q,1,0
u,n,o,1,1,p,q,1,1,0
u,n,o,1,1,p,1,q,1,0
u,n,1,o,1,p,1,q,1,0
2,h,i,j,k,l,v,w,a,0
2,a,b,c,d,u,x,y,z,0
2,0,0,0,0,1,1,2,1,0
2,0,0,0,0,1,2,1,1,0
2,h,a,b,u,i,x,y,z,0
2,0,0,0,1,0,1,2,1,0
2,0,0,0,1,0,2,1,1,0
2,h,a,b,u,x,i,y,z,0
2,0,0,0,1,1,0,2,1,0
2,h,i,j,u,x,y,k,z,0
2,0,0,0,1,1,2,0,1,0
2,h,i,u,j,k,x,y,z,0
2,0,0,1,0,0,1,2,1,0
2,0,0,1,0,0,2,1,1,0
2,h,i,u,j,x,k,y,z,0
2,0,0,1,0,1,0,2,1,0
2,h,i,u,j,x,y,k,z,0
2,0,0,1,0,1,2,0,1,0
2,h,i,u,x,j,k,y,z,0
2,0,0,1,1,0,0,2,1,0
2,h,i,u,x,j,y,k,z,0
2,0,0,1,1,0,2,0,1,0
2,h,u,i,x,j,y,k,z,0
Okay, I'm working on it! Give me time.drc wrote:This is getting really annoying:
Code: Select all
image
Code: Select all
x = 6, y = 3, rule = B34k_S23
3b2o$o3b2o$2obo!
Yes, that's what happens. That will be fixed in the next version as well.drc wrote:Also, this is commonly clasiffied as pathological:
I'm guessing it separates the block and glider.Code: Select all
rle
Code: Select all
# Remove any gliders:
if (glidersexist):
Code: Select all
# Remove any gliders:
if (glidersexist and stepsize < 8):
Code: Select all
# Remove Ts, if they exist:
if self.rg.t:
Code: Select all
# Remove Ts, if they exist:
if self.rg.t and stepsize < 8:
Yes. That's why I said to only use it in rules where glider tagalongs (or T tagalongs) cause too many pathological objects, not for rules with unidentifiable objects arising for any other reason (like replicators). Ultimately, this problem can be solved, but it will take quite a bit of time (and frankly, I'd almost prefer just to rewrite the whole thing).drc wrote:With the new hack, this showed up:
http://catagolue.appspot.com/object/xq4_163xac4/b36ns23