RE: Conway's Game of Life (cellular automata)

["Anton van Straaten" <anton@appsolutions.com>]

>    I'm not sure I follow you.  x & y is simply a concise way to
>    specify a set of nine cells, in this case, and potentially, a
>    larger set, although you're saying that for this specific
>    application a larger set isn't needed.
>
> Maybe I'm making an OOP point.  I'm just saying that `new-cell-state'
> doesn't need the values of x & y, but only the nearest cells, which in
> x/y lingo are of course are described by
>
> (x-1,y-1) (x-1,y) (x-1,y+1)
>
> (x,y-1)           (x,y+1)
>
> (x+1,y-1) (x+1,y) (x+1,y+1)
>
> Surely you agree.  And it would work just as well to describe these
> neighbors "relatively" instead of "absolutely" as I did:
>
> nw n ne
> w     e
> sw s se

This seems to be a question of data representation.  x & y are a way to
refer to the necessary data; nw/n/ne/w/e/sw/s/se represent the actual data,
rather than a reference to it (hmmm - is it that the former seems too much
like a pointer to you?? ;o)

Like any design decision, there are tradeoffs.  As we've already discussed,
using x & y gives you access to a broader context, which is potentially more
general; if, as you say, that's never needed - and ignoring the possible
advantages of generalized matrix-maps and matrix-sums - passing through the
necessary values works fine.  For me, and I'll admit this may just be
preference, the combination of only needing two values, plus the potential
generality of the coordinate solution, tips the balance in its favor.
However, I'm not arguing that either is intrinsically better.  I just didn't
understand your point initially.

Anyway, as I said in my first message, using x & y is a weakness, because it
detracts from the abstractness of the the program at that level.  If it
weren't for that, the top-level program would be sufficiently abstract to
support most reasonable implementations, including a list of lists.  That
might be "better" than both of our designs.  I don't think the nw/n/ne...
solution addresses this, because you still have to obtain those values
somehow, preferably in an implementation-independent manner.

A solution to this would be an abstraction for referring to the current
position on the board, which relates to the OO question.  I hinted at OO
approaches at the end of my first message.  An abstraction for a position on
the board could contain sufficient context to eliminate the need to pass x &
y, or nw/n/ne... etc. around as discrete parameter.

The question of which data representation to use would then move to the
internal representation of the abstraction in question, where it becomes
much less important.  It would be like asking whether the internal
representation of a "Point" abstraction should use polar or cartesian
coordinates - neither is "better", they're just different ways to represent
the same thing.

However, in this example, an abstraction sufficiently general to support
arbitrary implementations is likely to complicate the logic more than it
helps; I'd have to try it and see.

> which is pretty cumbersome, and I imagine slow as well, and I don't
> see that as any improvement over your matrix approach, other than
> being functional (no mutation).

The matrix approach I suggested can be fully mutation-free - as I said, all
you would need to do is use lists to build individual vectors.  I wouldn't
try pulling any of that icky "assignment" stuff on you!!

As Yoda might say: Assignment leads to mutation.  Mutation leads to
pointers.  Pointers lead to suffering!

Anton