[Tutor] Re: The Game of Life

[Max Noel]

	First of all, thanks for answering our questions, Danny! And sorry for 
the lag before my reply, but I was rather busy over the last few days 
(moving "back" to the UK).


On Jan 6, 2005, at 20:05, Brian van den Broek wrote:

> I am having a hard time figuring out how to efficiently snip and 
> comment, so please bear with any organizational issues. I think I will 
> just preserve the parts relevant to what I want to talk/ask about and 
> write at the end.

	And I hereby massively SNIP whatever remained of it. :D

> I gave some thought (though produced no code) to the question of how 
> to do a life game before you 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 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.
	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?


	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.
	If your world is a finite rectangle, I think the best you can get is a 
world where all but four cells (the corners) change next generation 
(same method). As your rectangle stretches to infinity, obviously, the 
cells changed/total cells ration converges toward 1.

	In any case, your point still stands.

> did you mean make the world a class (and thus avoid the sort of 
> passing the world dict up and down as I did here?) Either way, a quick 
> word or two will be great; I'm not asking for you to take the time to 
> code it up for me :-)

	Probably, but I don't think that's relevant.

-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting 
and sweating as you run through my corridors... How can you challenge a 
perfect, immortal machine?"