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 <rich...@damon-family.org> wrote: > > On 5/8/19 4:26 AM, Paul Moore wrote: > > On Wed, 8 May 2019 at 03:39, Richard Damon <rich...@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 -- https://mail.python.org/mailman/listinfo/python-list
