Maximum PC

I've been trying to create a simple implementation of Conway's Game of Life in Python. I have a logic error somewhere, but cannot seem to find it. I think it's in the process method, and it probably has something to do with my looping structures. Any help would be appreciated.

What have you done to fix it? What sort of logic error?

I don't have time to figure out your logic issues.

Is this homework?

No, it is not homework, personal project. I'm self taught and this is my first python script.
The first, randomly generated iteration works fine. In the next iteration, each row is the same. I have not been able to see what it is doing in between the first and second round, afterward, any cell surrounded on both sides of the repeated row dies, as do single cells, eventually leaving columns of two that do not die/move.
My approach is to cycle through each cell in each row, poll the surrounding cells, and sum them. The corresponding cell in the buffer is assigned a value accordingly. 3=dead, 2= same, else dead. Obviously, this is not what's happening. Any help lining up what I mean and what my code says?


EDIT: after more debugging, I found out
creates a whole lot of shared references. Not what I want.
redoing those loops in a bit, changing to while and defining buffer as empty, then appending.


Working Code:

Hey freak702... I just want to point out some things that you can do to improve your program (and programming). First, your code is hard to understand: 90% of the code is in a single function, you have NO COMMENTS AT ALL, and you've chosen some rather vague names for your functions. It's one thing to omit comments in a function named dfsSearch or mergeSort, but quite another in a function named algorithm or search... or process (which is actually misleading because usually functions with process in their name have something to do with concurrency).

Also, it isn't clear that how your program relates to the actual rules in Conway's Game of Live:



Below is a Common Lisp grid/matrix version of the game. Don't worry trying to understand all of the language (I didn't use any advanced language features, so it shouldn't be hard to follow). Notice that I have chosen to expand the grid by two rows and columns so that I don't need to check for the out of bounds conditions. This also makes counting the number of neighbors easier.

Also, it appeared that you were having some trouble with referencing the grid correctly. It is often easy to correct (or completely avoid) these types of errors by writing your program in a 'functional style'. You'll see an example of this in my next-grid function which accepts the current grid, then generates a new grid with each function call. No state, no errors. Sure, it uses more memory than either an in-place version or trying to alternate between two grids, but using a matrix is already horribly inefficient (think 10000x10000 sized grids) and doesn't allow you to expand indefinitely like in the real game.

I also added some code to check for a 'stabilized pattern', max number of iterations, etc. The main game code is below. Also notice that I've nested 3 functions inside my main function which is a common technique in languages that support it for creating 'private functions' (the inspiration for public/private access in the OOP world).



I also wrote a couple of helper functions to create the grids and hard-coded a few interesting starting configurations from wikipedia.



HTH's ... I'll post a followup with some of the configurations running.

The pulsar at the end is pretty cool. Hopefully the forum doesn't destroy the formatting.

I've split up and renamed some functions, and added comments. I know the rules call for an infinite grid, but I'm just making this to practice Python and see a pattern of 1's and 0's on the console, so I've limited the grid to the default Windows command prompt size. More Conway's Petri Dish, I suppose. I might add more features later (output settings, use predefined grids, etc.).

Much better! =)



I prefer using an oversized grid and array indices like above, below, left and right; I guueeessssss this is passable solution. =)


This might not work as intended. Sure, it tells you whether or not there are any live cells; However, you can reach states in the game where there are live cells, but they're never going to change, so you'll be stuck in an infinite loop.

Hey Freak720... how is your knowledge of functional programming idioms in Python? I'm starting to work on some software for derivatives trading/pricing and might need to port some code to Python for use with Sage (a mathematical interface to several open source mathematical packages written in Python).

Can/Do you know how to do the following?
1. Define function arguments using keywords, optional values, multi-length args, etc.


2. Pass a function as an argument. Define a function that accepts a function as an arguement.

In Common Lisp, functions and symbols have different namespaces. The #' is used to indicate the function namespace. For example, if I type #'< at the prompt by itself (ie similar to how you would type a variable name to find the value of the variable), the REPL replies with

When defining a function, you need to call it using the funcall function (CL is a bit messier then Scheme in this respect where you just use the function name)...


2. Use mapping functions.
I know that you can do some things without having to call a map function in Python. For example, if I have a list of integers lst, I can use lst*2 to multiply the contents by 2. The reason I ask is that Lisp (and Python) programmers tend to make heavy use of mapping functions (ie applicative programming as opposed to iterating all over the place with loops). I'm kind of curious how Python compares...

I think that I'm going to be making heavier than normal use of mapping function for time-series data, profits for various stock prices, and plotting graphs in Sage. One of the things that was giving me trouble while working with Sage involves the min and max functions. I need to be able to do something like the following...

3. Return a function.
At the moment, I'm thinking through the design, but one of the options that I'm considering includes writing a function that returns a function based on some input parameters. This is a toy example, but I'd like to know if it can be done...


4. Taking the previous example a step further, can you enclose a function (ie a function closure).


If you're not sure what is going on with the enclosure, don't worry about it. I can spend some time looking it up. It might be something that you'd want to figure out on your own though.

5. Compose a function [ie from mathematics g compose f(n) === g(f(n))].
Allows you to use functions orthogonally (eg for mapping, eval, etc). Instead of writing a function for a covered call, which is a combination of a written call and owning a stock, I might just compose a function using the written call and stock functions. Useful examples of this appear all the time... unfortunately, I can't think of any at the moment.

Thanks for any help that you might be able to offer.

1. Any argument may be accessed by its name. Default values can be defined as name=value in the arg list, not sure if this is what you meant by optional, but it can probably be used to implement whatever you did mean. Not sure what you mean by multi-length args, but you can use *name or **name in the function definition to match unmatched arguments(*name puts extra positional arguments from a call in a tuple, **name puts extra keyword arguments in a dictionary).



2. and 4. In python, functions are also objects, that can be passed around at will. to use a function as an object, simply omit the ().


3. I think I know what you're talking about. Actually, lst*2 does not evaluate to a list with each element *2'ed, instead, it is one list containing the elements of lst twice.

What I think you want are comprehensions.

you can use any expression (I think).

I believe that python automatically encloses any variables needed from the local scope at function definition.

I don't quite know what you mean with function composition, an example might help (it doesn't have to do anything useful, just demonstrate the similarity to composite functions in mathematics).

I'm a bit distracted with another project at the moment, but I plan on returning to Sage shortly. Thanks for the answers.


Pretty much. If an arg has been defined using a name value pair (ie name=value) and I leave the arg out of a function call, it will receive the default value, right?


No, that isn't what I meant, but that is a very interesting language feature. I'm going to have to think about some uses for it.

What I meant is easily demonstrated using an example. Say I need to write a function to sum integers, but I want it to be able to sum more than two integers because I don't want to have to write code that looks like this...

... just to sum 1, 2 and 3. Multiple-length args allows me to write the function so that the last argument is basically a list of values and then I can sum (or do whatever) across the list.


Nice... I like the get()() example. It is better if you say that functions are "first-class objects" which helps eliminate any confusion with OOP terminology.

Yeah, I wrote that and the next day it started bugging me, so I downloaded a new copy of Python for my laptop and saw the same thing. I think that Sage has added some type of list comprehensions to make mathematical operations like the example I gave easier within a limited GUI environment.


Sure. I should start by saying there is a decent wikipedia article on this subject (w/ an example in Python). One way to think of function composition is the idea of building a function from two or more functions. To keep things simple, we'll combine two functions, but in practice, you tend to get the most bang for you buck when you need to build with more than just two functions. This doesn't really address why you'd want to use composition though. The best answer that I can give is that the ability to compose functions makes a language more orthogonal (in case you don't know what I meant by orthogonal... children's building blocks are highly orthogonal, they work with each other so you can build a wide variety of things with them compared to say the furniture in a room which probably doesn't 'fit together' too well).

Another reason is you can write clearer code by eliminating multiple function calls (eg get()() in Python or (funcall (funcall get)) in Lisp). Now the get()() isn't too bad in your small example, but it would hurt the appearance of your code if you had more function calls (eg get()()()() esp if there are actual args) or if you're using it repeatedly. It tends to be less orthogonal when working with other language features. For example, if I'm using map to apply functions to a list of values, I would have to write a lambda function that calls get()(). OTOH, if I've used a function builder, I could just call the built function which is equivalent of get()(). Another reason for using a function builder is that we might not know which function to use until run-time. I don't necessarily mean this in a polymorphism sense either (ie which method should be called), I mean we might not know which functions until run-time (eg the user defines the function).

Here is fairly simple example. We're going to use print, the built-in timer function, and a sleep function. Let's say that I'm working with some external entity and sometimes I need to add a 1 second delay and other times a 2 second delay between sending messages. We'll say that our messages are sent when I print them. The protocol has "hello", "query" and "end" which take 1s, 2s and 1s, respectively. Let's say that my first script does something like... hello, query1, query2, end. Now the most obvious thing is to write a script like this...

Aside from the problem of boring you into a coma, there are some real problems with maintaining something like this script. First, in a longer script, there is a good chance that a typo will mean that you're not delaying the correct amount of time. Second, you can't very well work in an interactive environment in this manner, right? You'd send the command then have to use a stop watch or something... or type out the command (not starting it) and then the delay, then start both of them. Ugh. I don't know about you, but I don't do data entry!

We could write a function that takes a list of commands, iterates through it and does the correct amount of delay. This is a giant improvement, but it doesn't solve the interactive environment problem unless we know exactly everything in advance. It also isn't really orthogonal to the language. We're introducing a new piece of furniture, not something that plays nice with our existing blocks. It also another piece of code for us to maintain and the rather cheesy implementation I've done doesn't scale very well with dozens of additional commands.

I could break this apart and write individual functions like (defun hello () (print 'hello) (sleep 2)), which lets me do something like (hello)(query)(query)(end) and is than even foo, but I'm repeating the same basic code for each command. If there are a hundred commands, I'm still doing data entry, right? And what if some of the commands are more complex, and require additional things like checking for a response? Then both the foo script starts to break down and the individual functions per command becomes even more tedious.

What if we could write a function that built the function for us? Each command would then be a function call. If a command changed, I simply need to rebuild the one function. They're not all intertwined. Plus, I don't need to update any of the scripts because they'd simply be calling the new functions instead. Also, they're now building blocks that play nice with the rest of the language.

Of course, writing a function like new-foo() isn't exactly working with the language orthogonally. What i'd really want to do is use a map instead.


I think that is a pretty good example of composing functions. Of course, the make-cmd function that I wrote/used isn't very general. A true function builder would allow the user to pass in multiple functions at run-time. I was trying to keep things as simple as possible. One of the best uses of composition is called memoization. In a nutshell, if you have a very time consuming function that makes recursive calls, you can "memoize" repeated function calls. You pass your function to memoize which returns a new function that uses a hash table to store the result (the args are the key, the result the value). Repeated calls with the same key are retrieved from the hash table isntead of being computed. By using composition, you're able to write one memoize function that is able to work with any number of input functions (as opposed to some one off solution for a single function).