Conway's Game of Life, Element-by-Element Multiplication and a condition cancellation
<p>Good afternoon. </p>

<p>I'm working on a "Conway's Game of Life" simulation in Matlab. Being as I am not the best in the world at Matlab, I did a lot of research and read up as much as I could on different techniques to attack this problem. </p>

<p>Conway's game of life has four conditions: </p>

<pre><code>If a live cell has fewer than 2 live neighbors, cell dies. 
If the cell has two OR three neighbors, it lives. 
If a live cell has more than three neighbors, it dies as well. 
If a dead cell has exactly three neighbors, it is reborn. 
</code></pre>

<p>My main focus has been to get <em>some</em> sort of code working for the inner 'guts' of the Conway grid, where I know that each cell will have 8 neighbors, and we can look at each of those neighbors without too many problems. </p>

<p>Through some trial and error (and because if/then was getting gross), this was the code I tried to work through to solve some conditions of "Conway's Game of Life:" </p>

<p><img src="https://i.stack.imgur.com/vd339.png" alt="Conway Code"></p>

<p>The "plot patch" is a function our professor is requiring us to call in order to 'play' the conway simulation. I'm not including it here, because it doesn't seem necessary. Also ignore some of the commented stuff in the "for" loop about edge/corner conditions...I haven't quite gotten to that point yet since discovering I had problems with the 'guts' of the Conway grid. </p>

<p><strong>MY PROBLEM</strong></p>

<p>I have ran this code numerous times and was pleased to see that it appeared to be behaving properly: that is, when I ran it for x generations, my plot patch was showing changes from generation to generation, and that the "number of neighbors" count was correct. <strong>However:</strong> on looking harder at my matrices, I've been noticing that at the new iteration of matrix <code>A</code> e.g. <code>A(r,c)=A(r,c).*(nsum==2)+(nsum==3)</code>, whenever the <code>nsum</code> matrix row had both 2 neighbors and 3, the`2 neighbor occasionally becomes a cancelled condition. I'll give some examples below. </p>

<p><strong>Where it works as it should. Note that both nsum=2 and nsum=3 are still both live once reapplied to the 'A' matrix</strong></p>

<p><img src="https://i.stack.imgur.com/tSEtY.png" alt="Where Code Works"></p>

<p>I've been informed that I can't post more than 2 links, so I guess here's a description of when it gets weird. Say I have a matrix row from 'nsum' where my cell neighbors look like this: <code>[2 2 2]</code>. When the <code>nsum</code> matrix is re-multiplied to the <code>A</code> matrix, all but one of those neighbors abruptly cancels, and my new <code>A</code> row becomes <code>[0 0 1]</code>. Or, in another case, I had a cell line-up where <code>[2 1 2]</code>, but when put into the new <code>A</code> Matrix, it became <code>[0 0 0]</code>.</p>

<p><strong>What I tried</strong></p>

<p>I attempted to use operator such as <code>|</code> "OR" to change the conditions so that the new matrix looked at both <code>nsum==2</code> OR where <code>nsum==3</code>, but that created a bigger mess where my <code>nsum</code> matrix ultimately became a grid of zeroes. I stopped trying to use <code>&amp;</code> when I realized that the <code>&amp;</code> would look at a condition that is both <code>nsum==2</code> AND <code>nsum==3</code>, which doesn't seem right. </p>

<p><strong>My questions</strong>
So where did I go wrong? Why is the <code>nsum</code> matrix, when elem-by-elem multiplied by the A matrix, sometimes show both <code>nsum==2</code> and <code>nsum==3</code>, and other times not? What kind of logical step am I missing here? </p>

<p>Any guidance would be greatly appreciated. </p>

<p>Thank you for your time. </p>