The Turtle wrote:About the glider removal question:
Can you remove gliders based on this? (attached)
Sure. There are definitely safe zones where you know that a glider or spaceship can no longer possibly affect the reaction it has left behind.
It's a little tricky to define mathematically the exact boundaries of those safe zones, though. For example, you have to account for the fact that a pattern inside an MxN bounding box can theoretically send out waves that move at light speed for up to M/2 or N/2 ticks:
Code: Select all
x = 60, y = 31, rule = B3/S23
14b31o$14b31o$14b31o$14b31o$14b31o$14b31o$14b31o$14b31o$14b31o$14b31o$
14b31o$14b31o$14b31o$2b2o10b31o$b4o9b31o$2ob2o9b31o$b2o11b31o$14b31o$
14b31o$14b31o12b3o$14b31o14bo$14b31o13bo$14b31o$14b31o$14b31o$14b31o$
14b31o$14b31o$14b31o$14b31o$14b31o!
The Turtle wrote:Are there some drawbacks of using this method for removing spaceships?
Just the complexity of watching an active pattern, recognizing gliders and spaceships, and tracking them as they cross that safe-zone boundary. The funny thing about Golly is that for most purposes you can write much simpler code, and it will be just about as efficient.
Among other things, a pattern runs much more quickly in Golly once it has stabilized, especially in Hashlife -- though it usually runs faster in Quicklife before it stabilizes. So if you just want the stabilized part of a methuselah, let's say, and want to discard the gliders, it's fairly efficient to do something like this:
1) Run 2^10 ticks.
2) Check if the pattern has stabilized. If not, go to step 1, until you've passed some reasonable limit like 2^18. (In that case, which will be relatively rare, you probably have a switch engine, or maybe something more interesting.)
3) Note the bounding box of the pattern.
4) Run 2^20 ticks.
5) Copy out the part of the pattern inside the bounding box from step 3. All the gliders and spaceships will be safely somewhere else.
Then if you want to know what gliders and spaceships were generated, you can do pattern-matching on all the cells outside that bounding box, and you'll know everything about them. You could re-run the pattern and see where each one first appeared, if you wanted to. All of this can be done with much less code, and in about the same amount of time, as a script that worries about eight different safe zones and analyzes every generation of an evolving pattern.
Another possibility: the apgsearch Python script that feeds the Catagolue project does a fairly efficient job of recognizing when patterns have stabilized, so with a little work you could just borrow some code from that script. Depends on how much you want to know about the escaping gliders and spaceships -- if their exact location matters, it might be simpler to write your own code. Also, glider- and object-recognition code has been posted here and there on various forum threads over the years, so let me know if you want another sample-code link or two.
About the appending-to-a-list question, in case it's not completely clear:
chris_c wrote:Because "append" is a function that appends data to a list but has no return value itself.
Here's one more sample:
Code: Select all
var1 = [1]
var2=var1.append(0)
print var1
print var2
When Python executes "[1].append(0)" in your original example, it briefly produces a new extended list [1,0]... but the list that got modified wasn't ever stored in a variable, so it gets discarded, and the variable (originally "var", now "var2") just gets the nonexistent return value from the append operation.