Trouble with erlang-questions@REDACTED and www.erlang.org

[Marc Ernst Eddy van Woerkom]

Thank you for reviving erlang.org

Last weekend was the ICFP 2003 contest, and it was really bad luck 
that you went offline then.
The other bad timing was that I found out relative late about 
the contest date, just a few days before.

I hoped to join a team competing in Erlang, as tester or junior
member (relating to Erlang experience, not physical age :)
but found none. The mailing list was down, nobody alive showed up on
an erlang IRC channel I watched, no reaction to my message put on
the Erlang wiki, no reaction from other competitors who read
the contest web q&a forum (which was a bit misused for sideline 
communications). 
Where were you people? :)

The nice folks on #haskell at irc.freenode.net offered me to
learn Haskell in the remaining 1.5 hours before contest start,
but I decided rather to learn Erlang in that time span :)
and went on alone.

The experience was rather mixed.
I really like coding in Erlang.
But I have mixed feelings about the documentation.
Probably everything that is there, is described in detail somewhere.
So the reference is fine.
But advice on how to make good use of existing features for certain
problems is not enough in my humble opinion.

This year's problem was reading in a race track and calculating an 
optimal sequence of control commands for the racing cart, goal was
to minimize race time.
The maths was given and the formulas for the physical model.

A bit nasty was that we had three updates of the specs during the 
contest, but that involved mostly the extended sim for a tiebraker 
match, which is very likely not needed at all.

So I had to learn to read in tracks in .trk format and
write them as PNM graphics to visualize them in the GIMP.
I also wrote routines to read PNM graphics and output .trk
race tracks. So could use GIMP as editor.

I hade some trouble to get decent performance for
reading (ok) and writing (lousy) these files, each covering
1024x768 squares.
To find out, how to do that I/O at all, I looked at the
yaws sources to learn some tricks.

But the first problem was how to store matrix data
of the given size using Erlang.
I decided to use the RAL package, because I could
realize a vector data structure with it.
Perhaps some other solution would have been better
(ets?) but I had no time to do much research.

The other problem was how to implement the simulator
code in Erlang. It was given as an imperative
description with many ifs and whiles and I am not
sure if my transcription into functional Erlang
is adequate. 

I had differences in my test runs in the x,y,v,direction
data compared to the official test dump, and it 
turned out that I made a mistake 
translating V-= F0 + foo into V2 = V - F0 + foo ..
instead of V2 = V - (F0 + foo ..). Hmn.

As a one man show I was not fast enough in Erlang
to solve the real problem: optimizing the tracks.
So I took much time to create several race tracks,
which was fun.

I also recognized the canonical way how to solve the problem: 

This was a problem from theory of optimal control, which is a 
generalization of optimization theory. 

There one looks at a differential equation

  m dv/dt = F + C

where F is the force term that describes the physical 
behaviour of the system (in the contest: movement with 
linear and quadratic friction) and C is an additional
force that is used to control the movement (in the
contest: accelerating, braking, turning left, 
turning right). 
The task is to choose C in a way that a certain
quantity is optimal (in the contest: the 
racing time is minimal).

It is possible to solve for that C, but the examples
I could remember needed some nasty matrix maths.

Too bad I had no literature on control theory at hand,
but even so, formulating the problem right, applying
a solution and coding the solution would not have been
possible for me in time.

So I would have gone for a route as well, that many
participants chose.
Drawing manually a track in the GIMP and using that
as first order approximation of an optimal trajectory.
But I came not close to trying that out.

Some weird experience in between was transfering
my code on a Windows box and there it hung.
I don't know if perhaps some \n vs \r\n 
problematic hid there, and I had no time to
find out.

Very useful was Erlang's integer arithmetic.
Too bad I recognized my coding error too late.

All in all it would have been easier if one
had more folks than one on a team.
(Ok, there were some single guy teams who
 managed to solve tracks, my deep respect to
them).

I also wonder if one should prepare some 
optimization frameworks just in case for next
year's contest.

Regards,
Marc