[Newark] Life (Conway's Game of)

[Tom French]

Interestingly enough, I had a lab session on implementing the Game of Life
yesterday. Ours was done in Scala (which is based on Java) and was actually
an exercise in concurrency.

Y'see, this is why I keep telling you not to use Bash. Bash is slow, it's
incredibly slow. Similar code in almost any other language would run much
faster. That said, it does work and it looks right to me. You seem to be
blocking at the edges, like Steve's second suggestion. My implementation is
as if on a torus, so anything that goes off one edge comes back on the
opposite one, but either version works. Most proper implementations I see
work on a small section of a potentially very large grid, expanding the
section as needed, and presumably blocking at the edges.

Looking at your implementation, I expect pipe-lining so many copies of sed
is slower than chaining expressions with the -e option, and that might be
slower than writing a multi-line sed script. Bash isn't really equipped to
do the transformations itself, unfortunately, so it's probably going to be
slow anyway from the overhead of running a function on every cell that
spawns processes in serial. The rules can be implemented in a single
if-statement, but I doubt that would make a noticeable difference to the
framerate. I'm fairly certain, however, that no matter how much careful
optimisation you do, you're never going to get Bash to process Life at a
reasonable speed. So yeah, it's a nice hack but pretty difficult to
understand and very, very slow.

Now you've got the basic algorithm, though, it wouldn't take long to port it
to something reasonably fast, then you can try out the more fun custom
cellular automata. I made one that simulates forest fires by growing green
cells for trees and then randomly switching one to red for fire which
spreads and turns the trees to black ash.

Tom

2009/2/26 Chris Hayes <cbhworld at gmail.com>

> And now we have life, written in Bash:
> http://newark.lug.org.uk/wiki/doku.php?id=bash_life
>
> It's pretty slow, I haven't even tried to put in anything to boost
> efficiency. I found on my laptop, running Gnome I got roughly a frame a
> second on the bigger of the two patterns. On the test pattern I got around
> 2, maybe 2.5 frames a second.
>
> Please feel free offer critique although bear in mind it isn't meant to be
> pretty or good - it was really just a quick hack that gets the job done.
>
>
> Kind Regards,
> Chris Hayes
>
>
> On Sat, Feb 21, 2009 at 10:16 PM, Steve Caddy <steve.m.caddy at ntlworld.com>wrote:
>
>> Chris Hayes wrote:
>> > ... the only thing that I can't quite get my head around regarding life
>> is
>> > what order to calculate the cells in. I mean; if you work left to right,
>> top
>> > to bottom you'll get a different outcome than if you - say, do the
>> opposite.
>>
>> I'm under the impression that each generation is calculated from the state
>> of
>> its parent, but the new state isn't written to the grid until the entire
>> next
>> generation has been calculated. It's unimportant which order you consider
>> the
>> cells in, because all the neighbours are static during the calculation of
>> the
>> next generation. What is interesting to consider, is what happens at the
>> edge
>> of the playing area... should it wrap around, or should you consider the
>> edge
>> to be composed of permanently dead cells?
>>
>> Steve
>>
>> --
>> Steven M Caddy, MEng
>> ------------------------------------------------------
>> Email: steve.m.caddy at ntlworld.com
>>
>> _______________________________________________
>> Newark mailing list
>> Newark at mailman.lug.org.uk
>> https://mailman.lug.org.uk/mailman/listinfo/newark
>>
>
>
> _______________________________________________
> Newark mailing list
> Newark at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/newark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.lug.org.uk/pipermail/newark/attachments/20090226/11abf482/attachment.htm