SimFrost (#117)

The three rules of Ruby Q.:

  1. Please do not post any solutions or spoiler discussion for this quiz
    until
    48 hours have passed from the time on this message.

  2. Support Ruby Q. by submitting ideas as often as you can:

http://www.rubyquiz.com/

  1. Enjoy!

Suggestion: A [QUIZ] in the subject of emails about the problem helps
everyone
on Ruby T. follow the discussion. Please reply to the original quiz
message,
if you can.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

This was one of the Perl Quiz of the Week problems a couple of years
ago. It’s
also my favorite computer simulation.

The goal is to create a simulation of frost. The end result should look
something like this (13MB Quicktime Movie):

http://www.rubyquiz.com/SimFrost.mov

Of course, you don’t have to create a movie. Using the terminal is just
fine.

Here are the rules of the simulation.

First, create a two-dimensional grid to hold our simulation. The width
and
height must be even numbers. The top of this grid wraps (or connects)
to the
bottom and the left and right sides also touch, so technically we are
representing a torus here.

Each cell in the grid can hold one of three things: vacuum, vapor, or
ice. To
begin with, place a single ice particle in the center of the grid and
fill the
remaining space with some random mix of vacuum and vapor. You will
probably
want to leave yourself a way to easily adjust the starting vapor
percentage as
you begin to play with the simulation.

Display the starting grid for the user, then begin a cycle of “ticks”
that
change the current state of the grid. Redraw the grid after each tick,
so the
user can see the changes. The simulation continues until there are no
more
vapor particles. At that time your program should exit.

Each tick changes the grid as follows. First, divide the board into
“neighborhoods.” A neighborhood is always a square of four cells.
Given that,
on the first tick we would divide a six by four grid as:

±-±-±-+
| | | |
| | | |
±-±-±-+
| | | |
| | | |
±-±-±-+

However, even numbered ticks divide the board with an offset of one. In
other
words, the neighborhoods will be as follows in the second round:

| | |
-±-±-±
| | |
| | |
-±-±-±
| | |

Remember that the grid wraps in all directions, so there are still just
six
neighborhoods here. Later ticks just alternate these two styles of
dividing the
grid.

In each neighborhood, apply one of the following two changes:

  1. If any cell in the neighborhood contains ice, all vapor particles
    in the
    neighborhood turn to ice.
  2. Otherwise, rotate the contents of the neighborhood 90% clockwise
    or
    counter-clockwise (50% random chance for either).

For example (using " " for vacuum, “.” for vapor, and “*” for ice), the
first
rule changes:

±-+
| .|
|* |
±-+

into:

±-+
| |
|
|
±-+

The second rule changes:

±-+
|…|
| |
±-+

into:

±-+ ±-+
|. | or | .| 50% chance
|. | | .|
±-+ ±-+

Time is discrete in these ticks, so given some grid state at tick T all
neighborhood changes appear simultaneously in tick T + 1.

Again, use whatever output you are comfortable with, from ASCII art in
the
terminal to pretty graphics.

Quick clarification, I would assume you mean “turn 90 degrees”, not 90%,
as
that doesn’t make any sense.

Jason

On Mar 9, 2007, at 8:04 AM, Jason R. wrote:

Quick clarification, I would assume you mean “turn 90 degrees”, not
90%, as
that doesn’t make any sense.

Ick, yes. Good catch. I’ll fix it on the web site…

James Edward G. II

On 3/9/07, James Edward G. II [email protected] wrote:

Maybe you would like to clarify what the center is too (I’ll just use
the left hand upper corner of the center but maybe).

Cheers
Robert

On Mar 9, 2007, at 8:16 AM, Robert D. wrote:

Maybe you would like to clarify what the center is too (I’ll just use
the left hand upper corner of the center but maybe).

That’s what my diagrams are for, I hope. :wink:

To eliminate the idea of rotation, we could just say this: given the
neighborhood:

±-+
|12|
|43|
±-+

Change to:

±-+
|23|
|14|
±-+

or:

±-+
|41|
|32|
±-+

There’s a 50% chance to go either way.

James Edward G. II

On 3/9/07, James Edward G. II [email protected] wrote:

±-+
James Edward G. II

Sorry if I was not clear, I meant the center where to put the initial
freezer :slight_smile:
strictly speaking it does not exist in an even order grid, well I did
not think that was a problem but as you were about to update the
site…

The Quiz description is perfectly clear though apart this little
formalism.
Good work as always.

±-+

There’s a 50% chance to go either way.

James Edward G. II

these examples are rotation. Anything else would be permutations.
Could be done numerous ways. Array sorts, Rot13 (with only 4 digits.)
etc…

On Mar 9, 2007, at 8:59 AM, Robert D. wrote:

Sorry if I was not clear, I meant the center where to put the
initial freezer :slight_smile:

Oh, THAT center. :wink:

It doesn’t matter. I just used Ruby’s integer division.

James Edward G. II

On Mar 9, 2007, at 8:57 AM, John J. wrote:

±-+

There’s a 50% chance to go either way.

James Edward G. II

these examples are rotation.

Correct. This was just another way to describe it.

James Edward G. II

  • Ruby Q., 09.03.2007 13:58:

The three rules of Ruby Q.:

  1. Please do not post any solutions or spoiler discussion for this quiz until
    48 hours have passed from the time on this message.

  2. Support Ruby Q. by submitting ideas as often as you can:

http://www.rubyquiz.com/

  1. Enjoy!

What about using using nonstandard ruby packages? To in particular I
am talking about NArray:

NArray is an n-dimensional numerical array class. Data types:
integer/float/complexe/Ruby object. Methods: array manipulation
including multi-dimensional slicing, fast arithmetic/matrix
operations, etc.

http://rubyforge.org/projects/narray/

Josef ‘Jupp’ Schugt

  • Matthew M., 09.03.2007 21:38:

Strictly speaking, as this is a torus, you could put it anywhere
and be at “the center”.

Actually it only looks as if we are acting on a torus. The reason is
as follows:

We start with the physical problem that you have a center at which
freezing starts and an area around this center that can be dealt with
as if it is infinite in extension (meaning that we need not take into
account the surroundings).

For the simulation being feasible it is unavoidable to restrict the
simulation not only to a certain granularity but also to a certain
size of the simulated area[1] which means introducing a boundary into
the simulation that is not present in the simulated situation.

Now that we have an artificial boundary we need to find some clever
boundary conditions that limit artefacts to an unavoidable minimum.
Unless freezing takes place next to the boundary we can assume that
the leftmost region of the simulated area is not too different from
what is immediately to the right of the rightmost region of the
simulated area so that we can use it as an approximation of the true
state for this outside region (similar holding for the other sides).
This approximation obviously is quite good as long as the freezing
has not reached the boundary. But what if that happens? In the case
of the simulation we are dealing with it still is not too bad. The
reason for this is that the growth of the crystal starts at the
center of the simulated are so that the asymmetry present is a
reasult of the growth but not of the system itself being asymmetric.

In other words: While it at first sight may seems that the periodic
boundary conditions allow the center to be anywhere the truth is that
(quite the other way round) the fact that the center is in the middle
of the simulated area allows to use periodic boundary conditions (as
they are called) even after the frozen area has reached the
boundaries of the simulated area which otherwise would mark the end
of the validity of the simulation.

[1] Many of you may have heard that this is the second major issues
of the simulation of weather and climate simulation - the other
being the impossibility to simulate all the complex phenomena
involved in these processes (not even the most imporant ones).

Josef ‘Jupp’ Schugt

Again, use whatever output you are comfortable with, from ASCII art in
the
terminal to pretty graphics.

Could somebody point me in the right direction so I can find out how
to do pretty graphics?
Thanks,

Sorry if I was not clear, I meant the center where to put the initial freezer :slight_smile:
strictly speaking it does not exist in an even order grid, well I did
not think that was a problem but as you were about to update the
site…

Strictly speaking, as this is a torus, you could put it anywhere and
be at “the center”.

On Mar 9, 2007, at 4:40 PM, doug meyer wrote:

Again, use whatever output you are comfortable with, from ASCII
art in
the
terminal to pretty graphics.

Could somebody point me in the right direction so I can find out how
to do pretty graphics?

Well, I cheated. I wrote output frames in the PPM image format
because it’s dang easy and I’m dang lazy. Then I just joined them
into a movie with Graphic Converter.

If you’re familiar with an of the GUI toolkits though you could just
draw on some canvas object as you simulate.

What output options are the rest of you using?

James Edward G. II

How do we split the neighborhoods if the grid dimensions aren’t
divisible by 4?

Raj

Lol, sorry, forget what I just asked.

On 3/9/07, Josef ‘Jupp’ Schugt [email protected] wrote:

  • Matthew M., 09.03.2007 21:38:

Strictly speaking, as this is a torus, you could put it anywhere
and be at “the center”.

Actually it only looks as if we are acting on a torus. The reason is
as follows:

My fault for getting technical… someone else was bound to get even
more technical. =)

Any standard for the pixel width/height we should use for the
simulation? Have it as a command line option or some default value?

Raj

I failed to see one impact of where to put the initial freezer so far.
Now that I have eventually looked at James’ movie - great job James,
really nice - I imagine that it might indeed be a nice thing to start
the freezing process somewhere else than in the center of the
viewscreen that might nicely show how frost growth extends to the
other extremity of the viewscreen.

OTOH if someone can make a 3D movie of frost growth on a real torus :smiley:

Just an idea.

Cheers
Robert

On Mar 10, 2007, at 3:45 AM, Raj S. wrote:

Any standard for the pixel width/height we should use for the
simulation? Have it as a command line option or some default value?

I say use whatever looks the best.

James Edward G. II

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs