github
Advanced Search
  • Home
  • Pricing and Signup
  • Explore GitHub
  • Blog
  • Login

JustinLove / conwayslife

  • Admin
  • Watch Unwatch
  • Fork
  • Your Fork
  • Pull Request
  • Download Source
    • 1
    • 1
  • Source
  • Commits
  • Network (1)
  • Issues (0)
  • Downloads (0)
  • Wiki (1)
  • Graphs
  • Branch: master

click here to add a description

click here to add a homepage

  • Branches (1)
    • master ✓
  • Tags (0)
Sending Request…
Enable Donations

Pledgie Donations

Once activated, we'll place the following badge in your repository's detail box:
Pledgie_example
This service is courtesy of Pledgie.

Conway's Game of Life, from a two hour pair programming exercise with Justin Love and Dave Giunta — Read more

  cancel

  cancel
  • Private
  • Read-Only
  • HTTP Read-Only

This URL has Read+Write access

described interesting algorithm in readme 
JustinLove (author)
Thu Nov 05 19:24:33 -0800 2009
commit  fe60db5cb02af44f1d5f37f89f443f5cdaf0fd92
tree    ffb3ce6008fc364d11bbc07e545d90b01a6d4afc
parent  cfd3efb28d72a724e25ddb3ad930bd7cb22f5005
conwayslife /
name age
history
message
file README Loading commit data...
file life.rb
README
This project was part of a random pair programming exercise at the 2009-11-03 ChicagoRuby meeting.  The exercise was 
Conway's game of life.  This version was completed by Justin Love and Dave Giunta in about two hours.

What is particularly interesting about this implementation is that it actually operates on an infinite grid.  In certain 
places (especially live checking) the performance will suffer considerably for this, although that that might be 
addressed with some refactoring.

The basic strategy is a coordinate-indexed hash table of interesting cells.  Cells are interesting if they have a 
neighbor.  A version that addressed the expensive live-checks might also treat live cells as interesting in order to 
combine storage.

The table is created by iterating over live cells and incrementing the neighboor count around them.  Indexing the hash 
table by location allows you to have reasonable lookups of neighbor counts without allocating a finite grid.  Things can 
only happen to live cells or those dead cells next to live cells, so the process of calculating the neighbor counts also 
creates a list of the cells that have to be considered for births/deaths.

As a special case, the locations of live cells are not put into the table, so if it has no neighbors, it will not even 
be put into the hash table, and will 'die' by not being considered for the next generation.
Blog | Support | Training | Contact | API | Status | Twitter | Help | Security
© 2010 GitHub Inc. All rights reserved. | Terms of Service | Privacy Policy
Powered by the Dedicated Servers and
Cloud Computing of Rackspace Hosting®
Dedicated Server