I did icfp09 on my own using a mix of clojure+java. I'd sitll call myself a
clojure newbie, but have been writting java for a few years now. my code is
here:

http://github.com/mcodik/icfp2009-momo/tree/master

I wrote the vm in java since I figured that most of the code would be really
imperative with lots of writing/reading arrays and bit twiddling, both of
which I was more comfortable doing in java. My vm's main "run" method takes
in an IFn which it calls after every iteration.. this let me write all of
the physics code in clojure. I didnt really benchmark my vm at all until
just now, but looks like I get around 75k iterations/s on my thinkpad t60
with visualization disabled, and around 22k iters/s with visualization on.
the visualization is a simple swing ui that draws points and circles
representing orbits and sattelite positions (also written in java).

the only actually interesting part about the clojure code was the state
machine I ended up using: I had a ref set to a function of vm inputs ->
velocity change and on every vm tick I would call the function currently
assigned to the ref. I created a few of these functions that would do
specific things: I had one that would wait N vm ticks then ref-set another
function as the active one. Another would execute a burn for N ticks then
ref-set another active function when complete. The function that executed a
hohmann orbit transfer would compose these two and then set another active
function, etc. I was having a tough time getting things to happen when I
wanted to before I got the state machine going.

the code in that git repo solves 100x, 2001, 2003 and 2004. I never got 2002
to work due to some rounding error.. I'd always end up slightly outside the
1km range of the target sattelite.

overall, pretty fun contest... learned quite a bit doing it.

Maurice

On Wed, Jul 1, 2009 at 6:45 AM, igorrumiha <igorrum...@gmail.com> wrote:

>
> On Jul 1, 8:55 am, Nicolas Oury <nicolas.o...@gmail.com> wrote:
> > - Use java arrays for memory. You don't seem to use the vectors in a
> > persistent way, and there does not seem to be easy parallelization of the
> > vm. That's less elegant but probably quicker. I wouldn't say the same
> thing
> > if there were possible ways of using persistency later on in the problem.
>
> I have already started on that path, I have created an experimental
> version of the VM that stores machine state in Java arrays. That gives
> me around 100% speed increase (from 600 to approx. 1200 program
> executions / second).
>
> [SNIP interesting advice]
>
> This looks like an interesting approach. I will try it out. I have
> been avoiding the use of macros for some time now, maybe this is an
> ideal opportunity to learn how to use them :)
>
> --
> Igor.
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to