A short but hopefully sweet solution:
#!/usr/bin/env ruby
require 'enumerator'
require 'optparse'
rule = 110
steps = 20
cells = 1
OptionParser.new do |opts|
opts.on("-r RULE", Integer) {|rule|}
opts.on("-s STEPS", Integer) {|steps|}
opts.on("-c CELLS", Integer) {|cells|}
end.parse!
cells = cells.to_s(2)
steps.times do
puts cells.gsub('0', ' ').gsub('1', 'X')
cells = "00#{cells}00".split(//).enum_for(:each_cons, 3)
cells = cells.map {|neighborhood|
rule[neighborhood.join.to_i(2)] }.join
end
John Joyce wrote:
are these not fractals?
Some are, most aren't. The majority of rules (as far as I remember - not written my solution yet 
) come up with fairly dull stable patterns.
···
--
Alex
Thanks guys. I've updated the web site description.
James Edward Gray II
···
On Aug 10, 2007, at 9:49 AM, Gareth Adams wrote:
Craig Demyanovich <cdemyanovich <at> gmail.com> writes:
Noticed a typo in the quiz. 1110 is not 30 in binary; 11110 is.
...
binary, so we just
pad the right side with zeros and we have our table.
In addition, you'll be padding the left side, Shirley?
Sweet indeed, i like especialy the to_i(2), didn't thought about that.
But running your solution with rule 145 gave me
X
X
XX X
X X
XXX X X
X X X X
XX X X X
XXX X X X
XXX X X X X X
X X X X X X
XX XXX X X X X
XXX X X X X X X
XXX X X X X X X X
X X XXX X X X X X
XX XXX X X X X X X X
XXX X X X X X X X X
XXX X X XXX X X X X X X
X X XXX X X X X X X X X
XX XXX X X X X X X X X X
XXX X X XXX X X X X X X X
While my solution produced
0: X
1:XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX
2:XXXXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXXXXXX
3:XXXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXXXXX
4:XXXXXXXXXXXXXXXX XX X XXXXXXXXXXXXXXXXX
5:XXXXXXXXXXXXXXX X X XXXXXXXXXXXXXXXX
6:XXXXXXXXXXXXXX XXX X X XXXXXXXXXXXXXXX
7:XXXXXXXXXXXXX X X X X XXXXXXXXXXXXXX
8:XXXXXXXXXXXX XX X X X XXXXXXXXXXXXX
9:XXXXXXXXXXX XXX X X X XXXXXXXXXXXX
10:XXXXXXXXXX XXX X X X X X XXXXXXXXXXX
11:XXXXXXXXX X X X X X X XXXXXXXXXX
12:XXXXXXXX XX XXX X X X X XXXXXXXXX
13:XXXXXXX XXX X X X X X X XXXXXXXX
14:XXXXXX XXX X X X X X X X XXXXXXX
15:XXXXX X X XXX X X X X X XXXXXX
16:XXXX XX XXX X X X X X X X XXXXX
17:XXX XXX X X X X X X X X XXXX
18:XX XXX X X XXX X X X X X X XXX
19:X X X XXX X X X X X X X X XX
20: XX XXX X X X X X X X X X X
Anyone who can confirm one of these as 'correct' ?
cheers
Simon
···
alpha.chen@gmail.com wrote:
A short but hopefully sweet solution:
[...]
True, but some of the rules are very interesting.
Rule 30 passes many tests of random number generation, for example. Mathematica uses that very rule internally in it's algorithm for generating large random integers.
James Edward Gray II
···
On Aug 11, 2007, at 3:30 AM, Alex Young wrote:
John Joyce wrote:
are these not fractals?
Some are, most aren't. The majority of rules (as far as I remember - not written my solution yet ) come up with fairly dull stable patterns.
The first row isn't padded. It's that the later rows push it over. I started with:
X
Then Rule 2 fills the cell down and to the left:
X
X
And again:
X
X
X
Make sense now?
James Edward Gray II
···
On Aug 13, 2007, at 8:41 AM, Drew Olson wrote:
James Gray wrote:
On Aug 13, 2007, at 8:17 AM, Drew Olson wrote:
Note: I saw no reason to make the output right
justified, so mine is left justified. Not sure if this matters much...
I don't think the rules should be justified in either direction. The
pattern dictates how they expand.
Your code draws some rules differently, for example:
James -
Thanks for the follow up. I may be totally missing something, but I'm
confused where the left padding comes from in the first generation in
your solution.
I believe your code is correct and mine makes the same mistake as alpha.chen's code.
James Edward Gray II
···
On Aug 13, 2007, at 5:00 PM, Simon Kröger wrote:
alpha.chen@gmail.com wrote:
A short but hopefully sweet solution:
[...]
Sweet indeed, i like especialy the to_i(2), didn't thought about that.
But running your solution with rule 145 gave me
X
X
XX X
X X
XXX X X
X X X X
XX X X X
XXX X X X
XXX X X X X X
X X X X X X
XX XXX X X X X
XXX X X X X X X
XXX X X X X X X X
X X XXX X X X X X
XX XXX X X X X X X X
XXX X X X X X X X X
XXX X X XXX X X X X X X
X X XXX X X X X X X X X
XX XXX X X X X X X X X X
XXX X X XXX X X X X X X X
While my solution produced
0: X
1:XXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX
2:XXXXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXXXXXX
3:XXXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXXXXX
4:XXXXXXXXXXXXXXXX XX X XXXXXXXXXXXXXXXXX
5:XXXXXXXXXXXXXXX X X XXXXXXXXXXXXXXXX
6:XXXXXXXXXXXXXX XXX X X XXXXXXXXXXXXXXX
7:XXXXXXXXXXXXX X X X X XXXXXXXXXXXXXX
8:XXXXXXXXXXXX XX X X X XXXXXXXXXXXXX
9:XXXXXXXXXXX XXX X X X XXXXXXXXXXXX
10:XXXXXXXXXX XXX X X X X X XXXXXXXXXXX
11:XXXXXXXXX X X X X X X XXXXXXXXXX
12:XXXXXXXX XX XXX X X X X XXXXXXXXX
13:XXXXXXX XXX X X X X X X XXXXXXXX
14:XXXXXX XXX X X X X X X X XXXXXXX
15:XXXXX X X XXX X X X X X XXXXXX
16:XXXX XX XXX X X X X X X X XXXXX
17:XXX XXX X X X X X X X X XXXX
18:XX XXX X X XXX X X X X X X XXX
19:X X X XXX X X X X X X X X XX
20: XX XXX X X X X X X X X X X
James Gray wrote:
Make sense now?
James Edward Gray II
Ah yes, that makes perfect sense, thanks for the insight.
···
--
Posted via http://www.ruby-forum.com/\.
Forgive me for being dense, but I can't seem to figure out what the
mistake is. When I do it by hand, I get the same result as when I run
the script:
145 = 10010001b
[0 0]1[0 0]
[0 0]0 0 1[0 0]
1 1 0 0 1
Alpha Chen
···
On Aug 13, 3:12 pm, James Edward Gray II <ja...@grayproductions.net> wrote:
I believe your code is correct and mine makes the same mistake as
alpha.chen's code.
For any rules with a 1 in the final bit position, the edges should basically be an infinite strand of on cells. Remember, any cell that's not on is off, so you technically start with:
...00000000000000000000100000000000000000000...
All of those 000 neighborhoods turn cells on.
James Edward Gray II
···
On Aug 13, 2007, at 6:24 PM, Alpha Chen wrote:
On Aug 13, 3:12 pm, James Edward Gray II <ja...@grayproductions.net> > wrote:
I believe your code is correct and mine makes the same mistake as
alpha.chen's code.
Forgive me for being dense, but I can't seem to figure out what the
mistake is. When I do it by hand, I get the same result as when I run
the script:
145 = 10010001b
[0 0]1[0 0]
[0 0]0 0 1[0 0]
1 1 0 0 1
James Edward Gray II wrote:
..00000000000000000000100000000000000000000...
All of those 000 neighborhoods turn cells on.
James Edward Gray II
Yep. Ok i borrowed some ideas from Alpha Chen and tried to
remove everything evil from my solution. The result:
···
--------------------------------------------------------------
require 'optparse'
rule, steps, cells = 145, 20, '1'
OptionParser.new do |opts|
opts.on("-r RULE", Integer) {|rule|}
opts.on("-s STEPS", Integer) {|steps|}
opts.on("-c CELLS", String) {|cells|}
end.parse!
size = steps + cells.size + steps
line = cells.center(size, '0')
steps.times do
puts line.tr('01', ' X')
widened = line[0, 1] + line + line[-1, 1]
line = (0...size).map{|i| rule[widened[i, 3].to_i(2)]}.join
end
--------------------------------------------------------------
Well, not much new here but i think its clean and straight.
cheers
Simon