Life tag testing

[rowett]

I like option #2 better -- seems like there's an opportunity to define a standard syntax for non-totalistic rules. Doesn't seem as if there are any serious competitors.

Option #2 it is then.

I think we should stick with the base64 encoding, just as it is now in LifeViewer. A working example is nine-tenths of the battle.

OK. We can always add new number bases later.

Also note MAP supports alternate generation rules. MAP defines the even generation rule and MAPODD defines the odd generation rule. If there's no MAPODD defined then MAP is used for all generations.

To me that seems more like a niche experimental rule type, that could safely be left for lifeviewer.lua (or just LifeViewer) to support. I can't think of any reason why it would be a bad idea to include native support for it in Golly, though...?

The reason it exists is to support B0 emulation.

[dvgrn]

The reason it exists is to support B0 emulation.

Ah, of course. Interesting... but there might be another option here. The MAP string allows B0 rules to be specified perfectly well -- anything 'g' or later for the first character, right?

So maybe it would work to do B0 emulation behind the scenes in Golly, as it already is for Life-like rules. And then there'd be no need for a strange new two-line pattern header syntax, or a "special" first comment line or really long first line or whatever, to hold the MAPODD string.

-- Unless there's some other use case for what amounts to a 2^1024-sized rule space instead of a mere 2^512-sized space. But 2^512 already seems plenty big enough...!

[rowett]

The MAP string allows B0 rules to be specified perfectly well -- anything 'g' or later for the first character, right?

Yes, or in other terms, anything where the first bit in the 512 sequence is 1.

So maybe it would work to do B0 emulation behind the scenes in Golly, as it already is for Life-like rules.

Sure though I'm not sure of the algorithm for B0 emulation of the whole 512 bit map space which is why I went with the MAPODD approach, and LifeViewer silently zeroes the first bit.

[dvgrn]

So maybe it would work to do B0 emulation behind the scenes in Golly, as it already is for Life-like rules.

Sure though I'm not sure of the algorithm for B0 emulation of the whole 512 bit map space which is why I went with the MAPODD approach, and LifeViewer silently zeroes the first bit.

I think it's pretty easy when you have a nice clean 512 bits to work with, actually.

It will be something like

-- NOT (rule bitstring) for even generations, which zeroes the first bit,
-- (reversed rule bitstring) for odd generations. (EDITed to remove NOT as per a few posts down.)

I'll think about it a little more, maybe test it out with MAP and MAPODD, and edit in the results here.

EDIT: Looks good so far -- I've only checked it for a random isotropic rule, but at least in my head, X always lines up with NOT X if you reverse a (0..2^N-1) list, so the same algorithm should work for an asymmetric non-totalistic rule.

Code: Select all

Original rule:  B0124cik/S1c25
{oops, my script doesn't produce the right binary string for such rules yet, because Golly automatically translates the rule into its simulated flicker-free equivalent}

Rule for even generations:  B34-cik5678/S01-c34678 = 
00000001000101111010000110010111000101110111101110010111011111100001011101111111000101110111111001101111111111110111111011101001000101110111101110010111011111100111101111111111011111101110100101101111111111110111111011101001101111111111111111101001100101110001011101111101000101110111111001111111111111110111111011101001011110111101111101111110111010011101111101111111111010011001011101111101111101110111111011101001111111111111111111101001100101111111111111111111111010011001011111111111111111111001011101111111
ARehlxd7l34Xfxd+b/9+6Rd7l357/37pb/9+6b//6ZcXfRd+f/9+6Xvffunff+mXffd+6f//6Zf//+mX//+Xfw

Rule for odd generations:  B367c/S4etk678 =
00000001000101100000000000000000000101100110100000000000000000000001011001101000000000000000000001101000100000010001000001000001000101100110100000000001000001000110100010000001000001000010000101101000100000010000000000000001100000010001011101000001000101110001011001101000000000000000001001101000100000010000000000001001011010001000000100000000001000011000000100010110001000010001011101101000100000010000000000001001100000010001011100000001000101111000000100010110001000010001011100010110011110100001011101111111
ARYAABZoAAAWaAAAaIEQQRZoAQRogQQhaIEAAYEXQRcWaAACaIEACWiBACGBFiEXaIEACYEXAReBFiEXFnoXfw

Even-generation rule bitstring with bits in opposite order, compared with odd-generations rule -- should be exact inverse:
11111110111010011111111111111111111010011001011111111111111111111110100110010111111111111111111110010111011111101110111110111110111010011001011111111110111110111001011101111110111110111101111010010111011111101111111111111110011111101110100010111110111010001110100110010111111111111111110110010111011111101111111111110110100101110111111011111111110111100111111011101001110111101110100010010111011111101111111111110110011111101110100011111110111010000111111011101001110111101110100011101001100001011110100010000000
00000001000101100000000000000000000101100110100000000000000000000001011001101000000000000000000001101000100000010001000001000001000101100110100000000001000001000110100010000001000001000010000101101000100000010000000000000001100000010001011101000001000101110001011001101000000000000000001001101000100000010000000000001001011010001000000100000000001000011000000100010110001000010001011101101000100000010000000000001001100000010001011100000001000101111000000100010110001000010001011100010110011110100001011101111111
... and it is.

Isotropic B0 rules are still on the LifeViewer backlog, so use Golly or Molly on this for now:

Code: Select all

x = 37, y = 13, rule = B0124cik/S1c25
9ob8o3b5o2b9o$4bo5bo9bo5bo5bo$4bo5bo8bo12bo$4bo5bo8bo12bo$4bo5bo8bo12b
o$4bo5bo9bo11bo$4bo5b5o6b4o7bo$4bo5bo14bo6bo$4bo5bo15bo5bo$4bo5bo15bo
5bo$4bo5bo15bo5bo$4bo5bo8bo5bo6bo$4bo5b8o2b5o7bo!

This produces the same pattern at T=10 that Golly and Molly do:

Code: Select all

x = 37, y = 13
9ob8o3b5o2b9o$4bo5bo9bo5bo5bo$4bo5bo8bo12bo$4bo5bo8bo12bo$4bo5bo8bo12b
o$4bo5bo9bo11bo$4bo5b5o6b4o7bo$4bo5bo14bo6bo$4bo5bo15bo5bo$4bo5bo15bo
5bo$4bo5bo15bo5bo$4bo5bo8bo5bo6bo$4bo5b8o2b5o7bo!
#C [[ MAP ARehlxd7l34Xfxd+b/9+6Rd7l357/37pb/9+6b//6ZcXfRd+f/9+6Xvffunff+mXffd+6f//6Zf//+mX//+Xfw ]]
#C [[ MAPODD ARYAABZoAAAWaAAAaIEQQRZoAQRogQQhaIEAAYEXQRcWaAACaIEACWiBACGBFiEXaIEACYEXAReBFiEXFnoXfw ]]

Seems like a good sign. Some evening this week I'll maybe get around to changing a few bits to make this a proper asymmetric non-totalistic test case -- and also fixing my generator script so it gives the right answer for B0 and/or S8 rules (or at least notices and complains about them).

[rowett]

It will be something like

-- NOT (rule bitstring) for even generations, which zeroes the first bit,
-- NOT (reversed rule bitstring) for odd generations.

If this works out to be the case it will greatly simplify the B0 emulation code for the existing rule types also.

On an unrelated note I'll also allow Generations support for MAP rules.

[rowett]

It will be something like

-- NOT (rule bitstring) for even generations, which zeroes the first bit,
-- NOT (reversed rule bitstring) for odd generations.

When we do B0 emulation for Moore totalistic rules there are two cases:

1. B0 with S8 - we just invert to create one new rule (e.g. B03/S238 => B123478/S0123467)
2. B0 without S8 - we need two rules: one for even (e.g. B03/S23 => B1245678/S0145678) and one for odd generations (e.g. B03/S23 => B56/S58)

Will we not need the same (i.e. two different cases) for 512bit rules?

[dvgrn]

When we do B0 emulation for Moore totalistic rules there are two cases:

1. B0 with S8 - we just invert to create one new rule (e.g. B03/S238 => B123478/S0123467)
2. B0 without S8 - we need two rules: one for even (e.g. B03/S23 => B1245678/S0145678) and one for odd generations (e.g. B03/S23 => B56/S58)

Will we not need the same (i.e. two different cases) for 512bit rules?

Yes, no good applying the two-rule trick for a B0-with-S8 rule. As before, whenever we have a Rule X, we just need to create a new Anti-Rule-X and run that instead -- i.e. we assume that the pattern being run is already an inverted pattern.

The algorithm has to do the right thing when reduced to the simpler isotropic and Life-like cases. So for example a glider in AntiLife should be simulated as if it's a 5-cell hole in an all-ON universe, so it behaves just like Life.

It seems like the right answer is pretty clearly

B0 with S8 --
NOT (reversed rule bitstring) for all generations

That's got me a little worried about the non-totalistic odd-generation rule I proposed, though. In the isotropic and Life-like cases, it's not the same as the B0-with-S8 all-generations rule, so it shouldn't be the same here either. I'll have to get it all sorted out again in my head -- might take a day or so, I'm a slow thinker.

EDIT: No, I sorted it out on my bike ride to work this morning. What I actually tested was the following:

B0 without S8 --
-- NOT (rule bitstring) for even generations, which zeroes the first bit,
-- (reversed rule bitstring) for odd generations, which puts the zero S8 bit into the first bit.

That matches the above method for handling B0-with-S8, and it all reduces trivially to the isotropic and Life-like rule simulation method, so I think we're back in business.

[Apparently I got myself confused because the script I was running to generate the test 512-bit string, was running in Golly... and Golly was applying the B0-without-S8 rule and therefore giving me the wrong bitstring. I noticed, and corrected the example text, but somehow didn't notice that it was still backwards in the summary.]

[I should probably save all my hard thinking for when I'm biking back and forth to work -- I never get anything right any other time...]

[rowett]

I think we're back in business.

Excellent. So in our 512bit world we have the following:

• B0 means the first bit in the sequence is 1
• S8 means the 512th bit in the sequence is 1

So the pseudocode will be:

Code: Select all

if bits[0] == 1 then
    // B0 found
    if bits[511] == 1 then
        // B0 with S8
        ruleodd = NOT(reverse(bits[]))
        ruleeven = ruleodd
    else
        // B0 without S8
        ruleodd = reverse(bits[])
        ruleeven = NOT(bits[])
    end
else
    // no B0
    ruleodd = bits[]
    ruleeven = bits[]
end

[dvgrn]

EDIT 6/30/2017: Back in April the bit table in the rule-integer docs was officially rotated 180 degrees so that the most significant bit is in the upper left-hand corner, where it (maybe) belongs.

These test patterns come from an early alternate universe where the most significant bit was in the lower right corner. So in the test pattern comments, East is West and Northwest is Southeast, and so on. And vice versa. Try not to be confused for too long...

Some evening this week I'll maybe get around to changing a few bits to make this a proper asymmetric non-totalistic test case -- and also fixing my generator script so it gives the right answer for B0 and/or S8 rules (or at least notices and complains about them).

Well, my timeframe was a little unrealistic, but I'm still on the job. This version of the generator script --

Code: Select all

-- make_nontotalistic_LifeViewer_rulestring_v1.0.lua

local g = golly()
local gp = require "gplus"
local split = gp.split
-- local pattern = gp.pattern

function fixrule(s)
  return (gp.split(s,":")) -- remove bounded grid spec, if any
end

g.addlayer("temp") -- keep and test the current rule
fixedrule=fixrule(g.getrule())
g.setrule(fixedrule)

bitlist={{-1,-1,1},{0,-1,2},{1,-1,4},{-1,0,8},{0,0,16},{1,0,32},{-1,1,64},{0,1,128},{1,1,256}}
for j = 1, 9 do
    x, y, bit = table.unpack(bitlist[j])
    for i=0, 511 do
        if i&bit>0 then g.setcell(i*5+x,y,1) end
    end
end

g.run(1)
bits={}
ind=1
local rulestr, invstr, revinvstr="","",""
for k=0,2555,5 do
    if g.getcell(k,0)==1 then
        rulestr=rulestr.."1"
        invstr=invstr.."0"
        revinvstr="0"..revinvstr   
    else
        rulestr=rulestr.."0"
        invstr=invstr.."1"
        revinvstr="1"..revinvstr
    end
end

-- build base64 lookup table
local lookupstr="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
bdict={}
for i=1,64 do
    local w=""
    for j=0,5 do
        if (i-1)&2^j>0 then w="1"..w else w="0"..w end
    end
    bdict[w]=lookupstr:sub(i,i)
end

-- decide whether to use standard, inverted, or inverted-reversed bitstring, based on fixedrule
-- (assuming Golly is correctly simulating rules with B0, with or without S8, to avoid strobing)

-- the following won't work for anisotropic non-totalistic rules defined by MAP strings,
-- so we'll have to decode the MAP rulestring into a 512-bit string in that case, check first and last digits...
-- but in that case, we already know the string, so why are we running this script anyway?

if string.match(fixedrule,"B0") then rulestr = string.match(fixedrule,"S.*8") and revinstr or invstr end

local s = rulestr.."0000" -- pad so that len mod 6=0
base64=""
for i=1,511,6 do base64=base64..bdict[s:sub(i,i+5)] end
    
g.setclipstr(rulestr.."\n"..base64)
g.show("Copied to clipboard: "..base64)

-- Life = 'ARYXfhZofugWaH7oaIDogBZofuhogOiAaIDogIAAgAAWaH7oaIDogGiA6ICAAIAAaIDogIAAgACAAIAAAAAAAA'

-- does fine for the N and S directions. Here's the N version: cells appear to move south because they only turn ON when the north neighbor is on.

Code: Select all

#C minimal anisotropic rule where the neighbor to the north (only) triggers a birth
x = 34, y = 22
o9bo9bo9bo$bo9bo9bo$2bo9bo$3bo$4bo15bo$5bo13bo$6bo11bo5bo$7bo9bo5bo$8b
o7bo5bo4bo$9bo5bo5bo4bo$o13bo5bo4bo4bo$13bo15bo$33bo2$5bo8bo$4b3o$3b5o
$4b3o12b2o$5bo13b2o$27b3o$o9bo16b3o$27b3o!
#C [[ MAP IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]]
#C 00100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

However, there's something odd going on for the other six directions. Here's AnisotropicTestSW translated by the script, for example:

Code: Select all

#C minimal anisotropic rule where the neighbor to the southwest (only) triggers a birth
x = 34, y = 22
o9bo9bo9bo$bo9bo9bo$2bo9bo$3bo$4bo15bo$5bo13bo$6bo11bo5bo$7bo9bo5bo$8b
o7bo5bo4bo$9bo5bo5bo4bo$o13bo5bo4bo4bo$13bo15bo$33bo2$5bo8bo$4b3o$3b5o
$4b3o12b2o$5bo13b2o$27b3o$o9bo16b3o$27b3o!
#C [[ MAP AAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]]
#C 00000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

"AAAAAAAAAAC" puts a 1 in position #64 in the 512-bit string (counting the first bit as position #0) so that matches the SW neighbor in the diagram. But when you run it in LifeViewer, it behaves as if only SE neighbors cause a birth.

It's trivial to swap the X coordinates in the "bitlist" lookup table, so that the Lua script makes a LifeViewer MAP string that produces the correct behavior. But really I *think* my code is correct, which means that there's something backward in LifeViewer. Here's another test case, generated by the script from AnisotropicTestE.rule:

Code: Select all

#C x = 34, y = 22, rule = AnisotropicTestE:T50,50
x = 34, y = 22
o9bo9bo9bo$bo9bo9bo$2bo9bo$3bo$4bo15bo$5bo13bo$6bo11bo5bo$7bo9bo5bo$8b
o7bo5bo4bo$9bo5bo5bo4bo$o13bo5bo4bo4bo$13bo15bo$33bo2$5bo8bo$4b3o$3b5o
$4b3o12b2o$5bo13b2o$27b3o$o9bo16b3o$27b3o!
#C [[ MAP AAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]]
#C 00000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

The script produces the following test pattern (except in the AnisotropicTestE rule, without the multiple states) -- and then only the #32 central cell turns on when it's run for a tick, so the script puts out "AAAAAAI":

Code: Select all

x = 2557, y = 73, rule = LifeHistory
160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$
160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$
160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$
160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$160.B$
160.B$160.B$160.B$160.B$160.B$160.B$144.B15.B15.B$145.B14.B14.B$146.B
13.B13.B$147.B12.B12.B$148.B11.B11.B$149.B10.B10.B$150.B9.B9.B$151.B
8.B8.B$152.B7.B7.B$153.B6.B6.B$154.B5.B5.B$155.B4.B4.B$156.B3.B3.B$
157.B2.B2.B$158.B.B.B$159.3B$160.B4$4.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A
3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A
2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A
2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A
5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.
2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A
5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A
7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.
A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.
2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.
3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.
A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A
3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A
2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A
2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A
5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.
2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A
5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A
7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.
A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.
2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.
3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.
A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A
3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A
2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A7.A5.A3.2A5.A2.A.A3.2A2.3A$D4.D4.D4.D4.
D4.D4.D4.D3.AD3.AD3.AD3.AD3.AD3.AD3.AD3.AD4.C4.C4.C4.C4.C4.C4.C4.C3.A
C3.AC3.AC3.AC3.AC3.AC3.AC3.AC4.DA3.DA3.DA3.DA3.DA3.DA3.DA3.DA2.ADA2.A
DA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA3.CA3.CA3.CA3.CA3.CA3.CA3.CA3.CA2.ACA
2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA3.D4.D4.D4.D4.D4.D4.D4.D3.AD3.AD3.
AD3.AD3.AD3.AD3.AD3.AD4.C4.C4.C4.C4.C4.C4.C4.C3.AC3.AC3.AC3.AC3.AC3.A
C3.AC3.AC4.DA3.DA3.DA3.DA3.DA3.DA3.DA3.DA2.ADA2.ADA2.ADA2.ADA2.ADA2.A
DA2.ADA2.ADA3.CA3.CA3.CA3.CA3.CA3.CA3.CA3.CA2.ACA2.ACA2.ACA2.ACA2.ACA
2.ACA2.ACA2.ACA3.D4.D4.D4.D4.D4.D4.D4.D3.AD3.AD3.AD3.AD3.AD3.AD3.AD3.
AD4.C4.C4.C4.C4.C4.C4.C4.C3.AC3.AC3.AC3.AC3.AC3.AC3.AC3.AC4.DA3.DA3.D
A3.DA3.DA3.DA3.DA3.DA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA3.CA3.CA
3.CA3.CA3.CA3.CA3.CA3.CA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA3.D4.
D4.D4.D4.D4.D4.D4.D3.AD3.AD3.AD3.AD3.AD3.AD3.AD3.AD4.C4.C4.C4.C4.C4.C
4.C4.C3.AC3.AC3.AC3.AC3.AC3.AC3.AC3.AC4.DA3.DA3.DA3.DA3.DA3.DA3.DA3.D
A2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA3.CA3.CA3.CA3.CA3.CA3.CA3.CA
3.CA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA3.D4.D4.D4.D4.D4.D4.D4.D
3.AD3.AD3.AD3.AD3.AD3.AD3.AD3.AD4.C4.C4.C4.C4.C4.C4.C4.C3.AC3.AC3.AC
3.AC3.AC3.AC3.AC3.AC4.DA3.DA3.DA3.DA3.DA3.DA3.DA3.DA2.ADA2.ADA2.ADA2.
ADA2.ADA2.ADA2.ADA2.ADA3.CA3.CA3.CA3.CA3.CA3.CA3.CA3.CA2.ACA2.ACA2.AC
A2.ACA2.ACA2.ACA2.ACA2.ACA3.D4.D4.D4.D4.D4.D4.D4.D3.AD3.AD3.AD3.AD3.A
D3.AD3.AD3.AD4.C4.C4.C4.C4.C4.C4.C4.C3.AC3.AC3.AC3.AC3.AC3.AC3.AC3.AC
4.DA3.DA3.DA3.DA3.DA3.DA3.DA3.DA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.
ADA3.CA3.CA3.CA3.CA3.CA3.CA3.CA3.CA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.AC
A2.ACA3.D4.D4.D4.D4.D4.D4.D4.D3.AD3.AD3.AD3.AD3.AD3.AD3.AD3.AD4.C4.C
4.C4.C4.C4.C4.C4.C3.AC3.AC3.AC3.AC3.AC3.AC3.AC3.AC4.DA3.DA3.DA3.DA3.D
A3.DA3.DA3.DA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA3.CA3.CA3.CA3.CA
3.CA3.CA3.CA3.CA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA3.D4.D4.D4.D
4.D4.D4.D4.D3.AD3.AD3.AD3.AD3.AD3.AD3.AD3.AD4.C4.C4.C4.C4.C4.C4.C4.C
3.AC3.AC3.AC3.AC3.AC3.AC3.AC3.AC4.DA3.DA3.DA3.DA3.DA3.DA3.DA3.DA2.ADA
2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA2.ADA3.CA3.CA3.CA3.CA3.CA3.CA3.CA3.CA2.
ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA2.ACA$319.A4.A4.A4.A4.A4.A4.A4.A4.A
4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A
4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A
4.A4.A4.A4.A4.A4.A4.A4.A4.A5.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A
4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A
4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A
4.A4.A4.A4.A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A
3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A
3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A
3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A5.A4.
A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.
A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.
A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A4.A2.A.A2.A.A2.A.A2.A.A
2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.
A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A
.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.
A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A2.A.A
2.A.A2.A.A2.A.A2.A.A2.A.A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A
3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A
3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A
3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A3.2A
3.2A3.2A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A
2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A
2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A
2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A2.3A!

Have I got my thinking backwards somehow, or is this just somebody inventing new arbitrary coordinate systems again? If so, one possible fix would be to adjust the documentation:

Code: Select all

Neighbourhood
2 1 0
5 4 3  ->  4'
8 7 6

AnisotropicTestRules.zip

Minimal anisotropic rules. All are named after the neighbor that causes a birth -- so cells appear to move in the opposite of the named direction

(2.7 KiB) Downloaded 15 times

[rowett]

... is this just somebody inventing new arbitrary coordinate systems again?

This is entirely possible: a) MAP wasn't heavily tested since I was the only one using it. b) I'm left handed.

Would you prefer I fixed the MAP or the docs? I think I'd prefer to make MAP right handed but I don't mind.

I've made the following changes to Golly so far:

1. Implemented left handed MAP.
   • For 2-state rules the syntax is: rule = MAP<base64 string>
   • Bounding boxes are also allowed: rule = MAP<base64 string>:T200,50
   • For Generations rules the syntax is: rule = MAP<base64 string>/n (where n = 2 to 255)
   • Again, bounding boxes are allowed: rule = MAP<base64 string>/3:T200,50
2. Simplified B0 support so it works on the 512bit representations of 2-state or Generations rules.
   • One B0 to rule them all!
3. Increased maximum supported rule length (to protect Golly from badly optimized scripts).

Next I'll port this back to LifeViewer (except item 3 since LifeViewer has no limit on rule length).

[dvgrn]

... is this just somebody inventing new arbitrary coordinate systems again?

This is entirely possible: a) MAP wasn't heavily tested since I was the only one using it. b) I'm left handed.

I'm also left-handed. Should do a survey in the Sandbox of conwaylife.com forum members -- I bet there's a strong correlation between left-handedness and Lifenthusiasm, just as with mathematics and music and so on.

Would you prefer I fixed the MAP or the docs? I think I'd prefer to make MAP right handed but I don't mind.

Yeah, right-handed MAP please. If the left-handed docs had happened to be entertainingly memorable -- matching a numeric keypad layout or something -- that would be one thing, but right-to-left top-to-bottom is not terribly common (outside of Hebrew/Arabic/Persian, anyway).

I've made the following changes to Golly so far:

1. Implemented left handed MAP.
   • For 2-state rules the syntax is: rule = MAP<base64 string>
   • Bounding boxes are also allowed: rule = MAP<base64 string>:T200,50
   • For Generations rules the syntax is: rule = MAP<base64 string>/n (where n = 2 to 255)
   • Again, bounding boxes are allowed: rule = MAP<base64 string>/3:T200,50
2. Simplified B0 support so it works on the 512bit representations of 2-state or Generations rules.
   • One B0 to rule them all!
3. Increased maximum supported rule length (to protect Golly from badly optimized scripts).

Sounds good! The simplification does work out okay for known isotropic and B*/S* cases, right?

... As if 2^512 wasn't a big enough space to explore, now we have N*2^512 for Generations rules.

[rowett]

Sounds good! The simplification does work out okay for known isotropic and B*/S* cases, right?

Based on my limited testing - so far so good.

I'm also planning on deprecating the MAP script command in LifeViewer once the port is complete.

[dvgrn]

I'm also planning on deprecating the MAP script command in LifeViewer once the port is complete.

That's ... odd.

[rowett]

Odd? Seemed overkill to have native rule = MAP support and a [[ MAP ]] script command.

[dvgrn]

Odd? Seemed overkill to have native rule = MAP support and a [[ MAP ]] script command.

Oh, right. I was thinking of the MAPODD script command as a reasonable thing to deprecate, but was confusing script MAP with native MAP, so it seemed odd to deprecate functionality when you'd just gotten it working nicely.

Another topic: in terms of Next Items On The Agenda, if you might be able to use some help adding more scripting functionality to lifeviewer.lua, let me know. One thing you might do is point out some particular small isolated item that you'd rather not have to fix, and see if I actually get around to patching it successfully. I'm not always very good at finding time for coding projects -- would rather break things than fix them, I guess -- but it would be good practice for me to dive into lifeviewer.lua a little deeper.

Unless you already know what's wrong with ZOOM, I might start by investigating that, and/or the other items that I've reported as not working quite right -- see if I can understand the script well enough to make something work better.

[rowett]

Build 216 is now available on the lazyslug server

Enhancements in this build:

• native support for MAP rules - test
  • 2 state:
    • rule = MAP<base64>
    • rule = MAP<base64>History
    • rule = MAP<base64>:T100,50
    • rule = MAP<base64>History:T100,50
  • Generations:
    • rule = MAP<base64>/<num_states>
    • rule = MAP<base64>/<num_states>:T100,50
• deprecated [[ MAP ]], [[ MAPODD ]] and [[ FILL ]] script commands
• added non-totalistic rule B0 support - test

Fixes in this build:

• patterns were not correctly centred when bounded grid had a zero dimension - test
• Faders and Sticks aliases were incorrect - test

This build includes the simplification of B0 handling.

I've also implemented native MAP in Golly.

[rowett]

if you might be able to use some help adding more scripting functionality to lifeviewer.lua, let me know.

Thanks for the offer
Now I've finished the MAP stuff I'll get back to lifeviewer.lua (it's been a while!). I'll keep you posted.

[rowett]

Build 216 is now available on the lazyslug server

Assuming I didn't break too many things this should probably be a release candidate. Last LifeViewer release was back in August 2016. I blame Golly

[dvgrn]

Build 216 is now available on the lazyslug server

Assuming I didn't break too many things this should probably be a release candidate. Last LifeViewer release was back in August 2016. I blame Golly

Hm, this is odd. In the past I've been able to download a sample forum page, I think with either Chrome or IE, as the usual "Web page, complete" -- then swap out the lv-plugin.js file and effectively test the new version on a forum thread.

Now when I try this, .js files are getting converted to js.download files, and the plugin doesn't appear to add "Viewer" links successfully to the code blocks. Which means that all I have are the downloaded Viewer links, which point back to the actual conwaylife.com forum URL.

Did anything about the plugin's handling of Viewer links change recently? Or is this, I don't know, something new that my anti-malware software has decided to do, or something like that? Happened on two different machines the same way, though...

[rowett]

Now when I try this, .js files are getting converted to js.download files, and the plugin doesn't appear to add "Viewer" links successfully to the code blocks. Which means that all I have are the downloaded Viewer links, which point back to the actual conwaylife.com forum URL.

I see the same behaviour on Chrome. This appears to be a change in Chrome - nothing in LifeViewer has changed.
Unfortunately the solution appears to be:
1. Manually rename the .js.download files to .js
2. Globally search and replace .js.download with .js in the main downloaded "ConwayLife.com - View Topic.html" file.

[rowett]

Appears to work fine with Firefox.

[rowett]

Build 217 is now available on the lazyslug server

Enhancements in this build:

• overlay to display a live graph of population, births and deaths against generations
  • hotkey "y" toggles the display of the graph
  • hotkey shift and "y" to toggle graph lines (the default) or points
  • hotkey "7" to decrease and hotkey "9" to increase graph opacity (default 70%)

The updated keyboard map is here.

[rowett]

The new graph overlay in action:

[rowett]

Dave - please can you let me know if you're happy for Build 217 to be released to the forum and the Wiki? It has got several enhancements and a number of requested fixes.

[dvgrn]

Dave - please can you let me know if you're happy for Build 217 to be released to the forum and the Wiki? It has got several enhancements and a number of requested fixes.

Sure -- it's been near the top of my to-do list for several days now, which is usually a good sign. I'm a bit short of evening time this week, and other inconsequential Life things keep filling up the time.

I'll manage a decent review by the end of the weekend, anyway. If that's not fast enough, my quick look at your test pages says that it's probably an improvement on the status quo -- so really I'm happy with the release-now test-later roll-back-if-necessary model, too. Saves me some test setup time...!