raganwald / cafeaulife Goto Github PK

Some of these comments really seem unnecessary. for example:

# Export `Cell`
_.defaults exports, {Cell}

I think that is obvious enough that the code is "exporting" 'Cell'. I couldn't tell you why though.

My second criticism is that it seems comments are all too often of the "what" variety. Simply translating the code to english. That's not really very helpful. Once someone has some grasp of the programming language being used, the "what" is right there in the programming language. No need to restate it in another language.

--http://news.ycombinator.com/item?id=3577379

Is precomputing 65,536 seeds really a win? Maybe the time to compute the square is insignificant next to the time to allocate the objects and stuff them in the hash table. If we go this way, need to precompute the hashes as well. Which means that the seeds break if the hash function changes.

Or maybe they have their own hash function, a special case number from 0..65535. Which implies that hash codes should be independant of bucket sizes, which allows us to increase the size of the bucket list to create a cuckoo hash.

Defaults?

Canonicalize intermediate squares?

README.md should explain why the project exists, how to run it, and so forth. The source should explain the code.

Need to carefully think whether we can use Gosper’s quadtrees. Consider 4x4:

1122
1122
4433

In generation 1, we can change 1, 2, 3, and 4. In generation 2, we do:

....
.55.
.55.
....

Thus, a 4x4 square has a velocity of 2. Need to ponder whether larger squares can decompose to 4x4.

Need to be able to compute “rabbits” without going over 900,000 squares in the cache. Some options:

1. Roll your own weak references. They act like squares, but don’t remember results
2. Cache results but not squares, you can GC a bunch of results, which would discard a bunch of squares not currently ‘pinned’ by the current computation.
3. Figure out a ‘pinned’ vs. ‘unpinned’ flag for the cache, such that the current square is always pinned, and so are the initial rules, but other squares can be discarded. Critical to be able to force that any pinned square also pins its components, but nothing else is pinned. This allows for temporary results to be subject to GC.

Asking for too much from a square class. Consider moving the resize_to functionality out as well.

Use do or whatever. Pull it the funk out of constructor code.

given a value of n, it does nothing, inflates, or deflates as need be.

If a diagram is the best way to describe a function, use a diagram to describe a function.

perhaps a mirror bucket list? Crawl the tree hashing everything found that hasn’t already been added to the tree.

http://news.ycombinator.com/item?id=4646378

...which breaks results for non-trivial squares

And rename it hash code

Square.cache.find_or_create should know whether to calculate the result or perform it recursively.

The distinction between alive and dead only matters to the engine for hashing purposes. The rest of the potential logic should be reserved for the code that generates the level two seeds.

Move forward fewer than 2^(L-1) generations when generating a result.

Possibly degeneralize it and move the from_json stuff into the api module

Could this be the secret to optimizing 2^n+1?