As you may already know, it is perfectly possible to do with Haskell
what did with shell scripting, but we found shell scripting easier. I
don't see Haskell as a hammer for every nail, even though you can hit
a lot of things with it. (:
I'd like to clarify on the role of dynamic programming in this
contest.
More than one entry implemented dynamic programming: Rokicki's,
Sawicki's, and our winning entry. (We call dynamic programming "CYK
parsing", but as we explain in section 3.2 of our write-up, they are
the same thing.) Dynamic programming by itself is not enough, because
the algorithm takes time cubic in the input length, and with large
inputs it takes too long. Some "end-game" approximation technique is
therefore necessary. Rokicki didn't finish in time with his coding,
but Sawicki did put together dynamic programming with a simple
end-game technique. His entry placed 15th in your unofficial rankings
and did not officially qualify for the final round.
What made the difference between our entry and Sawicki's entry seems
to be the approximation techniques our entries used. Our technique
simplifies of techniques known to work in the parsing literature. We
couldn't have thought of what we implemented without the help of this
literature.
The bottom line: The programming language may matter (the essence of
dynamic programming is 10 lines of beautiful Haskell), but what is
more important is understanding the problem, relating it to existing
research, and taking advantage of previous work.
I would very much like to see a programming contest that is somehow
tinted towards imperative and object-oriented programming. I am
curious though -- what kinds of challenge tasks would you consider so
tinted? It can be difficult to come up with programming problems that
admit reasonably objective judging criteria, and for which submissions
can be expected to span a spectrum of quality from good to bad.
"There are several cellular services sold in North America. It's not possible to say that any one is best for everyone; there is much competition between the companies so most offerings are at least competetive."
"This web page has facts about the different services available. Since I live in Boston, I've included some details specific to Boston, but 95% of the information here applies to anyone in the US or Canada. There is a Boston page with info on Boston cellular companies with descriptions of each service, and some assorted notes on how cellular service works and how to decide what to buy. Finally, there is a database containing details about service plans and phones with an interface to let you match them up."
Slashdot Mirror
As you may already know, it is perfectly possible to do with Haskell what did with shell scripting, but we found shell scripting easier. I don't see Haskell as a hammer for every nail, even though you can hit a lot of things with it. (:
contest.
More than one entry implemented dynamic programming: Rokicki's,
Sawicki's, and our winning entry. (We call dynamic programming "CYK
parsing", but as we explain in section 3.2 of our write-up, they are
the same thing.) Dynamic programming by itself is not enough, because
the algorithm takes time cubic in the input length, and with large
inputs it takes too long. Some "end-game" approximation technique is
therefore necessary. Rokicki didn't finish in time with his coding,
but Sawicki did put together dynamic programming with a simple
end-game technique. His entry placed 15th in your unofficial rankings
and did not officially qualify for the final round.
What made the difference between our entry and Sawicki's entry seems
to be the approximation techniques our entries used. Our technique
simplifies of techniques known to work in the parsing literature. We
couldn't have thought of what we implemented without the help of this
literature.
The bottom line: The programming language may matter (the essence of
dynamic programming is 10 lines of beautiful Haskell), but what is
more important is understanding the problem, relating it to existing
research, and taking advantage of previous work.
I would very much like to see a programming contest that is somehow tinted towards imperative and object-oriented programming. I am curious though -- what kinds of challenge tasks would you consider so tinted? It can be difficult to come up with programming problems that admit reasonably objective judging criteria, and for which submissions can be expected to span a spectrum of quality from good to bad.
http://www.fftw.org generates pretty damn good Fast Fourier Transform code using an OCaml engine.
Please post a write-up! (:
Well, I was in the Chicago airport a while ago and at least in there I got VoiceStream coverage. So there.