[Tutor] Re: The Game of Life

[Brian van den Broek]

Max Noel said unto the world upon 2005-01-06 15:39:

<SNIP>

> 
> On Jan 6, 2005, at 20:05, Brian van den Broek wrote:
> 
> 
>> I gave some thought (though produced no code) to the question of how 
>> to do a life game before you [Danny] posted your code. My naive approach 
>> differs a bit, and it seems to me better. I'd like to know why I am 
>> wrong ;-)
>>
>> So, relying on your [Danny's] code unless differences specified (and, like you, 
>> not making it OOP, so having more passing of the world than I'd like, 
>> but I'm only just now groking the OOP way), I would have done 
>> something like the following. (Please be tolerant of any syntactic 
>> slips; I think and hope my aim is clear, if not the execution.):
>>
>> 1) Define world by filling an M by N matrix with True and False. 
>> Otherwise, as your step (1).
>>
>> 2) Define a print function which goes through the matrix, printing one 
>> thing for each True cell and another for each False cell.
>>
>> 3) Define the count_live_neighbours() roughly as you did. (The actual 
>> code below assumes your count function, modulo the change to it that 
>> you define a LIVE name and I am just using True.)
>>
>> 4) Define a "will be changed function" roughly as the untested code:
> 
> 
> <SNIP>
> 
>> 5) Define a get_changed_cells_list function (again, untested):
> 
> 
> <SNIP>
> 
>> 6) Define update_world function (again, untested):
>>
> 
> <SNIP>
> 
>> I hope the fragmentary nature of this makes my intent clear.
>>
>> Anyway, as I see it, this has the following advantages over your 
>> posted code:
>>
>> 1) Cell representations done with built-ins seems likely to be 
>> quicker. (A minor point, though.)
>>
>> 2) Use of booleans for cell contents makes the change cell procedure 
>> simply saying not
>> .> cell_contents  # as in for loop of my update_world().
>>
>> 3) Neither a copy of the world nor the design pattern is needed. 
>> Instead, I make a list of the cells to be changed. In the limit, where 
>> ever cell will change, this is no better than a copy of the world, but 
>> i) it often is better, and ii) I'm not sure the Life rules can create 
>> a world where every cell will change in the next generation, anyway.
>>
>> I don't see any disadvantages, but then I don't see too well ;-)
> 
> 
>     You're wrong in that you're not wrong. I'm not very familiar with 
> design patterns yet, but to me, what you just described looks like 
> another Life implementation using the Command design pattern. It is, 
> however, more efficient and IMO elegant than Danny's.

Well, thanks. :-)

>     Correct me if I'm wrong (I may be talking out of, er, a certain part 
> of my anatomy that is far from my mouth), but the basic idea of the 
> Command design pattern is to store the changes to be made (instead of 
> the post-change states) in a disposable data structure, then to apply 
> them to the original copy of the world. Which should be more efficient, 
> at least memory-wise. Right?


I don't know design patterns beyond the concept and a teeny bit of 
poking about. I guess I should check, but I got the sense that the 
Command pattern involved storing actual instructions instead of 
representational data. (Ugly term, but since Python functions are 
first-class objects I need something for data that isn't an 
instruction.) The sense comes more from the name than anything else, though.

>     Oh, the Life rules allow a world where every cell will change in the 
> next generation, iff your world is a torus (i.e. the lower row "touches" 
> the upper row as if it were immediately above it, and the right column 
> "touches" the left column as if it were immediately left of it). It is 
> quite trivial: set all cells to LIVE. Next generation they're all DEAD.

Topologist! (That's cheating!) ;-)

If we are going that way, you 'iff' seems a bit hasty. Take the 1x1 
matrix 'full' of live cells. Also, other 'funny' (in the sense that a 
torus is funny) planes could be defined (say a torus-like structure with 
more than 1 whole -- cannot recall the general terminology from 
ill-remembered topology), etc. I meant the claim for a standard 
non-trivial (i.e. M > 1 and N > 1) MxN euclidean plane matrix, but your 
correction is both amusing and welcome.

<SNIP>

Best to all,

Brian vdB