"Deficient" rules came up again on Discord today. I went looking around a bit, and found that there must be something wrong with the uploaded rule for B2_S34678_deficient. It's clearly not having the effect on patterns (either in Golly or in LifeViewer, which seem to behave identically) (whew) that is described in the text of the posted patterns:
I haven't tried regenerating the rule tree from the table, or regenerating the rule table via the Python 3 script in that thread.
Did you ever look into supporting deficient rules in LifeViewer directly, by the way? I see it was on the backlog in May 2019.
Here's a Discord link that gets at least into the general area where Caterer support for deficient rules gets some discussion:
"...any cell born with transition x will become a cell with the rule B(ruleB)-x/S(ruleS) for one generation, and then it reverts to B(ruleB)/S(ruleS)." The motivation is apparently to slow down explosions, to "tame" explosive rules and thus end up with a higher proportion of interesting rules.
Okay, now I've re-run RuleTableToTree.py on the table-format rule, and have gotten the same @TREE out as before, and it still fails to be equivalent to the @TABLE. If I remove the @TREE and just use the @TABLE, Golly simulates this pattern correctly:
That seems to indicate there's a bug in the RuleTableToTree.py script, that for some reason hasn't affected any other rule tables (that we've noticed yet). The variable names are unusually long and full of underscores, so possibly there's something going on there?
-- Further research when I'm feeling more inspired. Have to go out and shovel some snow now.
: Nope, the following version of the rule table works just as well to support the above pattern, but doesn't convert to a rule tree any better than before:
Code: Select all
n_states:8
neighborhood:Moore
symmetries:rotate4reflect
var aa = {1, 3, 4, 5, 6, 7}
var bb = aa
var cc = {1, 2, 4, 5, 6, 7}
var dd = cc
var ee = {1, 2, 3, 5, 6, 7}
var ff = ee
var gg = {1, 2, 3, 4, 6, 7}
var hh = gg
var ii = {1, 2, 3, 4, 5, 7}
var jj = ii
var kk = {1, 2, 3, 4, 5, 6}
var ll = kk
var mm = {0, 1, 2, 3, 4, 5, 6, 7}
var mm = mm
var nn = mm
var oo = mm
var pp = mm
var qq = mm
var rr = mm
var ss = mm
var tt = mm
var uu = mm
var vv = {1, 2, 3, 4, 5, 6, 7}
var ww = vv
var xx = vv
var yy = vv
var zz = vv
var w = vv
var x = vv
var y = vv
var z = vv
0,0,aa,0,0,0,0,0,bb,2
0,cc,0,0,0,0,0,dd,0,3
0,0,0,ee,0,0,0,0,ff,4
0,gg,0,0,0,0,0,0,hh,5
0,ii,0,0,0,jj,0,0,0,6
0,0,0,0,kk,0,0,0,ll,7
vv,0,ww,0,0,0,xx,0,yy,1
vv,ww,0,xx,0,0,0,yy,0,1
vv,0,0,ww,0,xx,0,0,yy,1
vv,ww,0,0,0,0,0,xx,yy,1
vv,ww,xx,0,0,0,0,0,yy,1
vv,0,ww,xx,0,0,0,0,yy,1
vv,0,ww,0,0,xx,0,0,yy,1
vv,ww,0,0,xx,0,0,0,yy,1
vv,ww,0,xx,0,0,0,0,yy,1
vv,ww,0,0,0,xx,0,0,yy,1
vv,0,ww,0,xx,0,yy,0,zz,1
vv,ww,0,xx,0,yy,0,zz,0,1
vv,0,ww,0,0,xx,0,yy,zz,1
vv,ww,xx,yy,0,0,0,0,zz,1
vv,0,ww,xx,0,0,0,yy,zz,1
vv,ww,xx,0,0,0,yy,0,zz,1
vv,0,ww,xx,0,0,yy,0,zz,1
vv,ww,0,0,xx,0,0,yy,zz,1
vv,ww,0,xx,0,yy,0,0,zz,1
vv,ww,0,xx,0,0,0,yy,zz,1
vv,ww,xx,0,0,yy,0,0,zz,1
vv,ww,0,xx,yy,0,0,0,zz,1
vv,ww,0,0,xx,yy,0,0,zz,1
vv,ww,0,xx,yy,zz,w,x,0,1
vv,0,ww,xx,yy,zz,w,0,x,1
vv,ww,xx,0,yy,zz,w,x,0,1
vv,0,ww,xx,yy,zz,w,x,0,1
vv,0,ww,xx,yy,0,zz,w,x,1
vv,ww,xx,yy,0,zz,w,x,0,1
vv,ww,xx,yy,zz,w,x,y,0,1
vv,0,ww,xx,yy,zz,w,x,y,1
vv,ww,xx,yy,zz,w,x,y,z,1
mm,nn,oo,pp,qq,rr,ss,tt,uu,0
I haven't traced through the @TREE format to see where it's going wrong, but it appears to be failing to process the very last rule line in the @TABLE. If I comment out that last line, I get the same exact pattern at T=200 as the incorrect @TREE gives me.
So... how many converted rules might be affected by this bug, whatever it is? Seems like it can't be a large percentage of them, or somebody would have noticed by now.
I haven't tried tracing through RuleTableToTree.py yet, to see why it's not processing that last line.