Intel® Software Network

It's late, so maybe I'm mental, but I think you're being too restrictive, or at least a little strange in the demo code, regarding the bounds of the region.

When reading in, and processing, you don't allow any cells to be set in row/col 0 or row/col MAXROW+1, despite having allocated room for them. I understand for internal calculation needing the border, but it seems strange to me to restrict the input that way.

I guess you could view it as starting at 1, rather than 0 for your counting. The WriteMap seems consistent with this -- so if you give a value of 0,0 for your upper left point, you should always have a dead top and left line.

Whatever. I guess, in a sense, you made it easier for us, but it seems a little odd for the 'user' creating the input files. If they put something on the border, it will get clobbered (though they'll be told about it).

Okay, I'll shut up now, I guess I've only potentially confused people.

jbstjohn:

When reading in, and processing, you don't allow any cells to be set in row/col 0 or row/col MAXROW+1, despite having allocated room for them. I understand for internal calculation needing the border, but it seems strange to me to restrict the input that way.

If you allowed them to be set, they would never be unset. Those values are not processed, and if your program did process them, it would ruin the whole reason to have a border since the code would have to check before it could index into the neighbor cells when processing those cells.

Mark

Strictly speaking, the implementation doesn't need the border, but it does make the processing simpler. An alternative approach used by some implementations of the Game Of Life is to join the opposite edges so that the right hand edge is assumed to touch the left hand edge, and the top and bottom likewise.

anthony_williams:

Strictly speaking, the implementation doesn't need the border, but it does make the processing simpler. An alternative approach used by some implementations of the Game Of Life is to join the opposite edges so that the right hand edge is assumed to touch the left hand edge, and the top and bottom likewise.

This way is simplier and much faster. Wraparound is another way to handle it but it would require additional if checks and additional wraparound calculations in the inner loop of the routine. Having these "non-inhabitable" border cells avoids all those checks and calculations.
Mark

anthony_williams:

Strictly speaking, the implementation doesn't need the border, but it does make the processing simpler. An alternative approach used by some implementations of the Game Of Life is to join the opposite edges so that the right hand edge is assumed to touch the left hand edge, and the top and bottom likewise.

Yes, this is implementation on torus. This one used very often for the Life game. Unfortunately it may give another output than defined task...