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
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
