[erlang-questions] write the ant simulation in Erlang?

[Daniel Goertzen]

How about 1 process for each cell, but no processes for the ants.  The ants
exist as state inside each cell and as messages interrogating neighboring
cells.  I think you'll get nice fine-grained localized transactions this
way.

Dan.

2008/10/10 Roger Critchlow <rec@REDACTED>

> I think the world process is the right idea.  It is supplying the semantics
> of the language runtime in Clojure which sorts out which speculative
> transactions are allowed to commit.
>
> Versioning of world state would need to restrict itself to the part of the
> world that the ant looked at, forcing a retry any time any part of the world
> had changed would be excessive.
>
> And I think that only moves resulting in ant-ant collisions need to be
> rejected -- that the rewards of moving might change between the time we make
> the decision and the time we enact the decision is unfortunate, but all too
> real.  The clojure ants are making decisions based on a snapshot, too, and
> only retrying on collisions.
>
> Capturing the snapshot for display should be simple, just return the
> world_loop State.
>
> -- rec --
>
>
>
> On Fri, Oct 10, 2008 at 12:47 AM, Brian Zhou <b88zhou@REDACTED> wrote:
>
>> On Thu, Oct 9, 2008 at 2:47 PM, Robert Virding <rvirding@REDACTED>
>> wrote:
>> > I haven't really checked the Clojure code that closely but it seems like
>> a
>> > reasonable problem.
>> >
>> > Do you know if it "turn based" or do the all the ants just move after
>> their
>> > own clocks in a parallel way?
>> The clojure implementation uses one thread for each ant. Each ant has
>> their own clock.
>>
>> >
>> > A first approximation would be to have one process per ant and one for
>> the
>> > world. The only problem would be handling atomic
>> > look-at-the-immediate-world-around-me-and-make-a-move.
>> >
>> Strictly speaking, the world state should be version'ed, the world
>> process should reject the move if the world has changed since the ant
>> looked, the ant process then should retry
>> look-decide-and-request-move. As an optimization, I guess the world
>> process can just check whether the FPA (food, pheromone, ant) value of
>> the target cell has changed.
>>
>> I wrote a rough first cut based on the above idea:
>> http://pastebin.ca/1224362 - It's not completed yet, TODO:
>> 1. pheromone evaporation
>> 2. initialization of the world, spawn world process, spawn ant processes
>> 3. scoring candidate cells
>>
>> Am I on the right track?
>>
>> > The really difficult bit is displaying it. :-)
>> >
>> I'm not there yet.
>>
>> Thanks,
>>
>> -Brian
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081010/7aac75dd/attachment.htm>