[Haskell-cafe] Reflections on Haskell and ICFP Contest 2009

[Lanny Ripple]

When you get bored or stumped with the problem you might pass your
time with Orbiter [http://orbit.medphys.ucl.ac.uk/].  Or you could
just use all the orbital mechanics math from the documentation.  :)

  Enjoy,
  -ljr

Rafael Gustavo da Cunha Pereira Pinto wrote:
> Hi All,
> 
> As the ICFP 2009 contest (http://www.icfpcontest.org) approaches its end, I
> decided to write down some thoughts I had while trying.
> 
> On Friday I downloaded the task (http://www.icfpcontest.org/task-1.9.pdf),
> read it for a while, and, since my goal is to finish by Xmas, went to the
> swimming pool. :-D While swimming, I started to think on the problem, and
> realized that the task is almost too easy for Haskell. Actually the task was
> so easy, that they added a final, non-scoring, task for those who have
> finished early.
> 
> This year's task is to build a VM that runs a (simple) program that
> simulates the physics of a satellite. The VM code has no branches, acting
> like a huge pocket calculator. The mission is to create a simulator that
> interact with this VM and maneuver the sattelite(s) on predefined patterns.
> 
> Here is how it went:
> 
> 1) Reading the orbiter data file:
> 
> The orbiter data file is a stream of 32-bit unsigned integers, which are
> commands, and 64-bit double precision IEEE-754 floats, which are data,
> forming a 96-bit frame. For this part I decided to use the Data.Binary
> module from hackage. The module is great, and it is very simple to use. But
> that took me 3 hours to learn how to use it (which, with my "honey-do" list
> ended up to be in Sunday morning)
> 
> By Saturday night I was cursing "The Binary Strike Force" because
> 
>           a) get :: Word32 reads it in little-endian
>           b) get :: Double reads the result of an decodeFloat, which has no
> resamblance at all with IEEE-754 standards
>           c) I spent the entire Saturday (2 hours, honey-do excluded)
> thinking I was doing something wrong!!
> 
> I was really pissed of, until I found "getWord32le" and "getWord64le", which
> solved 80% of the problem. The final blow was to decode the Word64 encoded
> IEEE-754 float into a Haskell float, which took me another honey-do-free
> hour.
> 
> First step solved. (BTW: I am attaching the first version to this e-mail. I
> will upload to Hackage upon completion, when getIEEE754float64le and
> putIEEE754float64le functions are done!)
> 
> 2) Running the VM:
> 
> This is the step I am working on. A really good and obvious approach to run
> the VM is to use a RWS monad, since:
> 
>          a) I have a fixed environment (the program and the input ports)
>          b) I have a state (the program counter, the status register and the
> data memory contents)
>          c) I have a monoid output (the output ports)
> 
> This is my recurrent complaint (a rant, maybe): this really important monad
> is completely undocumented, left for the developer to figure out how to use
> it. Even each of the singular monads (Reader, Writer and State) is poorly
> documented.
> 
> I will do some toy programs to understand each one. Let's hope I can create
> a hands-on tutorial on the RWS monad.
> 
> 3) Controlling the sattelites
> 
> This is going to be a piece of cake (aheeem! Just kidding!!). After
> computing the VM iteration, another computation will take the output data
> time series and estimate the next move.
> 
> It will be a piece of cake, considering I would have learned enough of
> Haskell state monads on step 2 to have just to worry about the physics of
> the problem!!!
> 
> 
> I'll keep you updated as my tests go, and hopefully I will have a working
> demo of the task written in Haskell by Xmas... 2010! ;-)
> 
> Best regards,
> 
> Rafael Gustavo da Cunha Pereira Pinto
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe