Re: [stella] And now, for my next trick...

Subject: Re: [stella] And now, for my next trick...
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Mon, 12 Mar 2001 12:47:42 -0500
>> I don't get it.  That's a nice compression for the average and best cases,
>> but the kernel and algorithm have to be able to handle the worst case.
>> What if a large-scale stable situation develops - all stable patterns (2x2
>> blocks, 6-cell ovals, etc, 3-in-a-row alternators, etc) separated by empty
>> gaps 2-4 cells wide?
>Then my proposed implementation could not handle it.  This is a limitation I
>was aware of, and am prepared to put up with.  It won't be perfect - but
>will be good enough for most cases.  I doubt, under most circumstances, it
>would ever be noticed.

How exactly do you "not handle" it - just drop the data from the last part
of the board that won't fit into the storage?  Still doesn't sound
appealing to me - it may just be the effects of my almost-completed CS
degree, but I really don't like such an elegant process as Life being
affected functionally (in this case, actively corrupted) by the RAM of its
simulator system.

A closer look shows that for the generation processing, one needs to store
one row of the shorter dimension of the rectangle plus 2 cells.  You could
do a 32 x 30 uncompressed and still have scratch space for the processing.
To get the 40 x 64 that you wanted, you have to achieve a 2.666:1 (8:3)
compression ratio (and that would also have a weird aspect ratio on screen
in excess of 2:1.)

Archives (includes files) at
Unsub & more at

Current Thread