<div dir="ltr">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.<br><br>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.  <br>
<br>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.<br>
<br>Capturing the snapshot for display should be simple, just return the world_loop State.<br><br>-- rec --<br><br><br><div class="gmail_quote">On Fri, Oct 10, 2008 at 12:47 AM, Brian Zhou <span dir="ltr"><<a href="mailto:b88zhou@gmail.com">b88zhou@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Thu, Oct 9, 2008 at 2:47 PM, Robert Virding <<a href="mailto:rvirding@gmail.com">rvirding@gmail.com</a>> wrote:<br>

> I haven't really checked the Clojure code that closely but it seems like a<br>
> reasonable problem.<br>
><br>
> Do you know if it "turn based" or do the all the ants just move after their<br>
> own clocks in a parallel way?<br>
</div>The clojure implementation uses one thread for each ant. Each ant has<br>
their own clock.<br>
<div class="Ih2E3d"><br>
><br>
> A first approximation would be to have one process per ant and one for the<br>
> world. The only problem would be handling atomic<br>
> look-at-the-immediate-world-around-me-and-make-a-move.<br>
><br>
</div>Strictly speaking, the world state should be version'ed, the world<br>
process should reject the move if the world has changed since the ant<br>
looked, the ant process then should retry<br>
look-decide-and-request-move. As an optimization, I guess the world<br>
process can just check whether the FPA (food, pheromone, ant) value of<br>
the target cell has changed.<br>
<br>
I wrote a rough first cut based on the above idea:<br>
<a href="http://pastebin.ca/1224362" target="_blank">http://pastebin.ca/1224362</a> - It's not completed yet, TODO:<br>
1. pheromone evaporation<br>
2. initialization of the world, spawn world process, spawn ant processes<br>
3. scoring candidate cells<br>
<br>
Am I on the right track?<br>
<div class="Ih2E3d"><br>
> The really difficult bit is displaying it. :-)<br>
><br>
</div>I'm not there yet.<br>
<br>
Thanks,<br>
<font color="#888888"><br>
-Brian<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>