Conway's game of Life, just because.

[Paul Moore]

Golly <http://golly.sourceforge.net/> supports both bounded and
unbounded universes. I don't know how it does it, and (obviously) it
will hit limits *somewhere*, but I consider support of unbounded
universes to mean that any failure modes will not be attributable to
limits on the value of co-ordinates (for the pedants out there,
ignoring issues such as numbers to big to represent in memory...)

It does limit *editing* of patterns to co-ordinates below a billion
(to quote the "Known Limitations" page). But that's a distinct issue
(I guess related to the GUI toolkit being used).

Disclaimer: I've only made very light use of golly, most of the above
is inferred from the manual and reports of how others have used it.

Paul

On Wed, 8 May 2019 at 12:38, Richard Damon <Richard at damon-family.org> wrote:
>
> On 5/8/19 4:26 AM, Paul Moore wrote:
> > On Wed, 8 May 2019 at 03:39, Richard Damon <Richard at damon-family.org> wrote:
> >> My experience is that the wrap around is common, as otherwise the hard
> >> edge causes a discontinuity in the rules at the edge, so any pattern
> >> that reaches the edge no longer has a valid result. The torus effect
> >> still perturbs the result, but that perturbation is effectively that the
> >> universe was tiled with an infinite grid of the starting pattern, so
> >> represents a possible universe.
> > In my experience, "simple" implementations that use a fixed array
> > often wrap around because the inaccuracies (compared to the correct
> > infinite-area result) are less disruptive for simple examples. But
> > more full-featured implementations that I've seen don't have a fixed
> > size. I assume they don't use a simple array as their data model, but
> > rather use something more complex, probably something that's O(number
> > of live cells) rather than something that's O(maximum co-ordinate
> > value ** 2).
> >
> > Paul
> >
> An implementation that creates an infinite grid to work on doesn't need
> to worry about what happens on the 'edge' as there isn't one.
>
> I suspect an implementation that makes an effectively infinite grid
> might not either, though may include code to try and keep the pattern
> roughly 'centered' to keep away from the dragons at the edge.
>
> If, like likely with a 'high efficiency' language with fixed sized
> integers, the coordinates wrap around (max_int + 1 => min_int) then it
> naturally still is a torus, though processing that case may add
> complexity to keep the computation of a typical cell O(1). You might end
> up with numbers becoming floating point, where some_big_number +1 -> the
> same some_big_number that would lead to issues with the stability of the
> data structure, so maybe some hard size limit is imposed to prevent that.
>
> So it comes to that if there is an edge that you might see, the normal
> processing is to wrap to make the edge less disruptive. If you aren't
> apt to see the edge, then it really doesn't matter how it behaves (sort
> of like how people aren't concerned about the Y10k issue)
>
> --
> Richard Damon
>
> --
> https://mail.python.org/mailman/listinfo/python-list