Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

ICFP 2003 Programming Contest Results 101

Posted by michael from the pedal-to-the-metal dept.
An anonymous reader writes "The previously reported ICFP Contest has been over for quite some time. The results were announced on August 26, 2003 at the conference in Uppsala, Sweden, yet the contest organizers have yet to publish results. Despite the forgetfulness of the organizers, it is known that this year C++ did well, taking first and second, but not judge's prize. Interestingly, a one-man team consisting of an undergraduate student took first place, followed by a team of highly ranked 'red' TopCoders, with the maintainers of Gwydion Dylan taking judge's prize."
This discussion has been archived. No new comments can be posted.

ICFP 2003 Programming Contest Results More

ICFP 2003 Programming Contest Results

Comments Filter:

  • Godspeed, Andrew Hudson (Score:5, Interesting)

    by stevesliva ( 648202 ) on Sunday September 14, 2003 @02:08PM (#6958175) Journal
    I wonder how many job offers 1st place winner and UT undergrad Andrew Hudson is going to receive... or for you conspiracy folks out there, how many shadowy organizations he'll be "invited" to join.

    • A more interesting question might be how many offers have gone to someone who's consistently done well two or three times but never won. By my count, there is at least one such person, looking at the most recent contests.

      This year's contest was an interesting problem, and no doubt the winning entry was well done, but there's also an element of brute force involved; look at the hardware Andrew had available. You could make a reasonable argument that this year's winner wasn't decided purely on programming s

      • You could make a reasonable argument that this year's winner wasn't decided purely on programming skill, and an even more reasonable argument that doing well in one such contest doesn't say nearly as much as doing well in multiple consecutive ones with different problems to solve.

        Andrew Hudson has gone to the ACM International Collegiate Programming Contest twice (the maximum allowed) and placed 21st and 27th, done well in local university contests, and is ranked highly on TopCoder. While it is unfortuna

      • So far as I can see, out of the top 3 or 4 solutions, his was by far the most likely to work well. Now, that might be partly luck, but given the technical sophistication, and the fact that he actually got his strategy to work, and work well under such tight time pressures; I don't think it was luck at all.

  • Awesome (Score:5, Interesting)

    by be-fan ( 61476 ) on Sunday September 14, 2003 @02:10PM (#6958183)
    Its nice to see my two favorite languages take the top spots :) Its also pretty nifty that the Gwydion Dylan team got another prize. They got second place a couple of years ago too. Anyway, more people need to check out Dylan. [gwydiondylan.org] Its a pretty nifty language. It was made by Apple in the early 1990's, by a committe containing a lot of important Lisp people. As a result, its kind of an object-oriented Lisp with a more traditional syntax. Its a very powerful language, but also very fast. It was designed to achieve 90% the performance of C. In practice, the current Gwydion compiler (designed by the same group at CMU that did CMUCL) achieves 50-90% given similar code.

    • Re:Awesome (Score:2, Insightful)

      by Anonymous Coward
      But the uniformity of the syntax of lisp (actually VERY traditional, going back to 1958...) is one of its major advantages.

      Dylan, a bit like Python, is a "gateway" language. People start using it, and slowly come to realise what makes lisp great. Then they make the leap to Lisp. Handy :-)

      • Re:Awesome (Score:4, Interesting)

        by be-fan ( 61476 ) on Sunday September 14, 2003 @02:30PM (#6958258)
        Dylan has some nice features that I didn't find in Common Lisp. Like Smalltalk, Dylan is objects "all the way down." Its also got some nice performance features like limited types and sealing. Overall, its just more elegant because it doesn't have the baggage of evolution and a standardization committe. This makes little difference in practices --- its mostly conceptual cleanliness. But Dylan is my hobby programming language (I do C++ at work) so I get to be arbitrary and choose elegance over practicality. That said, from my experience with Scheme, I have to say the prefix syntax is growing on me, and I'd love to see a resurrection of prefix-Dylan.

        • Re:Awesome (Score:2, Interesting)

          by Anonymous Coward
          Technically, Common Lisp is objects all the way down, too, actually. The confusing thing is that methods are specialised on types, not objects, and builtin methods can't always be truly extended or overridden (though you can create identically named methods in different packages). Check out recent thread "Everything is an Object" on comp.lang.lisp.
          • That's the bit that bothers me, that built-in methods can't always overridden. Like I said, this is largely a conceptual problem I have with CL, not a practical one.

      • But the uniformity of the syntax of lisp (actually VERY traditional, going back to 1958...) is one of its major advantages.

        I agree that Lisp's syntax makes many things easy -- stuff that can't be done as elegantly in other languages -- but it's not that old. Google for "M-Expressions"; example links: here [c2.com] and here [stanford.edu].

      • Re:Awesome (Score:2, Insightful)

        by andreas ( 1964 )
        There are two advantages with the Lisp syntax: it is easy to write parsers for, and is easy to write powerful macros that make the syntax extensible.

        Now we don't have 1958 anymore, and writing parsers for high-level languages is no black art anymore. A proper syntax makes code easier to read and to maintain, and laziness on the side of the compiler writer cannot be held up as an argument to make usage of the language harder to the user.

        And Dylan introduces a macro system that works much like the Lisp macr
      • Lisp syntax is TOO simple, just not expressive enough. When 2x^2+3x-4 becomes (- (+ (sq (* 2 x))) (* 3 x)) 4) then something is wrong. I prefer the extra complication of operator precedence; learned once, it simplifies the code forever... just like many of the other syntactic quirks of other languages. And no static type checking? And although the syntax is very simple, can we say the same for Common Lisp as a whole? If people didn't want/need some complexity, Lisp would be Scheme.
        • Since common lisp is already a *strongly typed* language, type checking is easy. You can have whatever level of type checking you want - you just have to code accordingly.

          Since common lisp is a *dynamic* language, you can't have static type checking. Indeed, static type checking is only a meaningful concept when it is possible for the compiler to know the type of every program entity at compile time.

          The desire for static type checking betrays a false understaning of the nature of programming - i.e., the i
          • As you admit, most tasks in programming _do_ operate on predictable data; the main area in which an algorithm wants to handle unpredictable data is surely the construction of generic libraries, for which purpose static, but polymorphic, typing, as in Haskell or ML, or to a lesser extent C++ templates, does a pretty good job. The earlier AC reply to your post mentions a type-inferring version of Common Lisp - type inference being a mechanism which provides the security (and speed!) of static typing with nea
            • To bring this back on topic, it's worth noticing that the ICFP programming contest has never been won by a dynamically-typed language...

              That's true and I think very interesting, as I pointed out in my 2001 writeup [hoult.org].

              Of course what I didn't know when I wrote that was that our dynamically-typed language (Dylan) ended up in 2nd place that year (and with the Judges' Prize this year).

              Also, a team using Erlang won the Lightning Prize in 2001, and a programmer using Python won the Lightning Prize in 2002.

  • Useful programming challenges (Score:5, Interesting)

    by JusTyler ( 707210 ) on Sunday September 14, 2003 @02:12PM (#6958193) Homepage
    Congratulations! I've usually steered clear of checking out programming "challenges" because they usually seem to be focused on producing the most unreadable or obscure code to confuse the judges.

    While you can learn things from obfuscated code, I think these practical challenges are a lot better for the programming community as a whole.

    Finding optimal paths around race tracks and obstacles [utexas.edu] presents a number of challenges which when solved in multiple totally different ways, helps give us new theories and data which we can use to develop new algorithms and theories for use in the real world.

    Can anyone recommend any other programming challenges which focus on developing new algorithms which may be useful in other disciplines?

    The only example I can think of is the many "robot" fighting challenges, where you write a program for a robot, and it has to destroy the other robots within the battlefield using its own "wits" and no human input. You might remember PC-ROBOTS from the early 90's if you're a real geek ^v^
    • Can anyone recommend any other programming challenges which focus on developing new algorithms which may be useful in other disciplines?

      The only example I can think of is the many "robot" fighting challenges, where you write a program for a robot, and it has to destroy the other robots within the battlefield using its own "wits" and no human input. You might remember PC-ROBOTS from the early 90's if you're a real geek ^v^

      It sounds like you are making reference to robocode [ibm.com], but it's hard to tell since yo

  • That's great (Score:2, Funny)

    by Anonymous Coward
    That's great, but he used SCO code. And he coded all this while listening to illegal MP3's. SCO and the RIAA are filing a joint suit against his grandmother.

  • Non-functional programming languages (Score:5, Interesting)

    by jfengel ( 409917 ) on Sunday September 14, 2003 @02:29PM (#6958254) Homepage Journal
    I guess it should come as no surprise that the winners should be programming in the decidedly non-functional (no pun intended, really) language C++. There are far more C++ programmers out there than Dylan, Haskell, and ML combined, probably by a couple orders of magnitude.

    The prizes were awarded based on answer quality, not performance, which takes away one of C++'s natural advantages over functional languages. Still, I'd like to see a breakdown of entry languages.

    • Re:Non-functional programming languages (Score:4, Insightful)

      by Haeleth ( 414428 ) on Sunday September 14, 2003 @02:47PM (#6958324) Journal
      Funnily enough, I came away with the impression that C++ had an advantage this year, since the removal of the requirement that the judges run the program themselves meant, in theory, that a brute-force approach combined with a supercomputer could have beaten the most delicately honed algorithm imaginable. That the winner was not an example of this surprised me.

      Ah well. Those of us with functional inclinations can console ourselves with the knowledge that at least the winning program didn't use COBOL...

    • Re:Non-functional programming languages (Score:4, Interesting)

      by Ben Escoto ( 446292 ) on Sunday September 14, 2003 @03:02PM (#6958372)
      It is a bit of a surprise that C++ won, because in previous years the winners were usually using Ocaml or Haskell (two "modern" functional languages with an advanced type system).

      In previous years, the majority of the entries were not C or C++. See for instance the 2002 entry list [ogi.edu]. In fact the entry list is interesting in itself to see all the languages people use.

      And it's true that there are more C++ programmers, but many of the smart ones probably experiment with other languages. On the other hand no one is programming Haskell now because that's the only thing they learned in school and they want a job somewhere.

    • 2002 ICFP language breakdown (Score:5, Informative)

      by truth_revealed ( 593493 ) on Sunday September 14, 2003 @03:43PM (#6958549)
      Values taken from the ICFP 2002 webpage and munged with an awk script... not 100% accurate, but close enough.

      language entries

      java 28
      c 24
      c++ 22
      caml 19
      python 15
      perl 11
      scheme 7
      haskell 6
      lisp 5
      dylan 2
      erlang 2
      mercury 2
      pltbot 2
      ruby 2
      ada 1
      bot! 1
      dogs 1
      extensions 1
      forth 1
      icon 1
      kylix 1
      lspm 1
      mhotas 1
      pandemonium 1
      pps 1
      prolog 1
      sk 1
      smalltalk 1
      sml 1
      v202 1

      Some languages are bogus because of the format of the author's entry, or they used multiple languages.

      • Re:2002 ICFP language breakdown (Score:1, Interesting)

        by Anonymous Coward
        It's interesting to note that even though there were a lot of Java entries - more than any other language - they did not rank very highly. The sheer number of programmers for a given language does not necessarily lead to better solutions in that language.
      • I'm disappointed by the overall poor performance of Java. Another poster pointed out that there was limited time to bang out the program, and I personally consider Java to be faster to program in than C++, especially for larger programs.

        Perhaps the size of the task was small enough that C++'s memory difficulties don't occur. If your memory requirements are low enough that you don't need to free memory, you eliminate an important source of wild-goose-chasing that often occur in C++ programs. One crash ca
        • Or perhaps they use smart pointers.
    • The competition was judged on performance in a way. The contestants had only so much time to prepare their entries, and much of that time must have been eaten up by their programs doing computation. The winning entry had an element of brute force computation together with a clever method to reduce the amount of computations. C++ sounds like a good choice for that approach.
    • The winner may have used files with a .cc extension and he may have used a few standard library constructs but it's a C program, not a C++ one.

  • I wonder (because I see no mention of it) how many different languages we used in the contest aside from the standards (C++, C, etc). Recently I've been playing with Ruby which is pretty handy at times, and I swear by python, and expect. Well coming from a sysadmin background I swear by these... Anyone know if languages like these were entered or,, even if others use python and expect on a normal basis, hell even ruby for that matter.
    • Yes, previous years have featured Python and Ruby contestants. I believe one year Python won the judge's award, but IIRC neither language has come in first or second.

      I think the problem with Python and Ruby are that they are both about 10+ times slower than Ocaml/C++ (to name two lanuages that often do well in the contest) and often running time is heavily weighted in the scoring.
  • What the hell does 'red' TopCoders mean? They were red-heads? They were Russian? They programmed all night and needed Visene to clear up their eyes?

    • Re:'red' TopCoders (Score:2, Informative)

      by jaxdahl ( 227487 )
      Take a look at the topcoder.com site. It's a periodic competition with short round matches that take a little over an hour to complete 3 challenges. These challenges are similiar to ACM competitions, but quite a bit easier b/c of the time limitations. The rankings are given in points kind of like chess, and the highest ranked coders are color-coded red. Below that is yellow and so on. Thus the best coders are 'Red coders'.

    • Re:'red' TopCoders (Score:5, Informative)

      by lars ( 72 ) on Sunday September 14, 2003 @03:49PM (#6958580)
      TopCoder [topcoder.com] is a company that recruits programmers, sells software components, runs high school contests, etc. (They probably do other things now too.) One of the main ideas behind the company is to rate programmers as objectively as they can. This acknowledges the fact that experience or specific skills on a resume don't necessarily provide a good indication of the programmer's true ability and productivity. The main way TC evaluates coders is based on programming competitions and component design and development competitions.

      I've been participating in TC's programming contests for more than a year. There are weekly contests, each of which take only about 90 minutes of your time. There are no prizes given out for the regular contests any more, but I really enjoy being able to get a nice mental workout, and compare myself to some really elite programmers. Most of the top-ranked coders have done extremely well in other prestigious international math and programming contests. And even if you aren't at the level of the top ranked guys (mostly - I think the highest ranked woman is around 50th or so, it would be nice to see more female participation), it can still be fun to work on improving your rating and other statistics such as submission accuracy. The rating system is modelled after the FIDE system for rating chess players.

      There are many other reasons to participate. You can also learn a lot by looking at the submissions by the top ranked coders. If you're looking for a job and do reasonably well, there's a good chance one of the many sponsor companies will be interested in hiring you. And perhaps most of all, TC has two big tournaments each year - the open, and the college invitational. These tournaments usually have a total prize purse of $100,000 or more, and pay out $50,000 or more to the winner.

      Finally, to answer your question; the TC ratings brackets are split up into different colours. 'Red' is the highest bracket, and includes anyone with a rating higher than 2199. This corresponds to roughly the top 2% of all rated members.

  • Access to fast machines required? (Score:4, Informative)

    by Ben Escoto ( 446292 ) on Sunday September 14, 2003 @03:23PM (#6958462)
    This contest concerned virtual racing tracks. The winner was the one who submitted the trace which would pilot the car as fast as possible around the track. (See the problem description [chalmers.se] for more information.)

    Thus the judges never ran the program on their computers, and in theory could have judged the contest without even looking at source code. To me this seems a bit unfair because the winner could just be the one with the fastest computer, not the best code. I noticed that the first prize team used 16 dual Xeons.

    So did anyone here compete? In practice are the results greatly influenced by how much hardware the contestants had access to?
    • The "speed" was in simulation ticks, not elapsed time.
      So on a 486 or a 16x-Xeon, 3000 ticks is 3000 ticks, doesn't matter how long it took to simulate in real time.
      • well they were the person who won completed all the tracks in the shortest total steps, where 1 step is one unit of time. They did not get judge on the amount of cpu clocks cycles it took so yes having a faster machine would definitely help as stated in the rules pdf. A 486 might have taken a week or longer to achieve the same result using the same algorythm

    • Re:Access to fast machines required? (Score:1, Informative)

      by Anonymous Coward
      Actually, it was never intended to become a raw computational task.

      The "idea" that we organizers thought would be the winning one was computer assisted manual driving, and that the task would become writing a GUI for that purpose. Which would have been pretty much CPU-power independent.

      • Re:Access to fast machines required? (Score:4, Interesting)

        by mvw ( 2916 ) on Sunday September 14, 2003 @10:43PM (#6961087) Journal
        The "idea" that we organizers thought would be the winning one was computer assisted manual driving, and that the task would become writing a GUI for that purpose.

        I was aiming for manual assisted computer driving. Something like providing the control points and let the computer draw the Bezier spline.

        To brute force the general problem I wouldn't dare in the first place.

        I wasted most of the time reading and writing stuff between the various formats and to get my simulator implementation running exactly like the official one. Which was probably 1-2 days too much. Coming up with such an optimizing GUI would have taken another 2-3 days for me.So the winners did a good job.

        Regards,
        Marc

    • I entered using a fairly average machine (Apple powerbook G4). It looks like I came in 30th out of about 90 entries (I'm "apple2gs"). I'm disappointed that I had to find out results through slashdot.

      My strategy was to try to use "waypoints" to help guide an optimizing algorithm, but I gave up and just made a manual car simulator (meaning, you manually enter the commands, and my program just shows where the car is and if it's hit a wall yet). With more time, I could easily improve most tracks by at least
    • Access to fast machines probably made a big difference in the results, and this was a major change from past ICFP competitions (which were run by the judges under fixed time constraints).

      The winner noted:

      I used 17 Dual P4 1800Mhz computers. (Without the permission of the CS Dept... sorry guys no time to get permission..)

      (here [dyndns.org])

      He also probably wrote the least amount of code of anyone. (A link to his source is posted in the same forum.)

      To be fair, he also took an approach that my team wrote off as una

  • when you dont even understand the problem.

    I read the dylan entry description and didnt even understand the problem. *smacks head*

  • ICFP stands for... (Score:1, Informative)

    by Anonymous Coward
    International Conference on Functional Programming.

    Just in case anyone wants to know without clicking through the fifth link to find a page that actually tells you...

  • Inrternational Conference On Functional Programmin (Score:3, Interesting)

    by Anonymous Coward on Sunday September 14, 2003 @06:33PM (#6959724)
    Somethign nobody has mentioned yet (at least with a high rating) is that this is the contest for the International Conference on Functional Programming, and not only that, from the rules page [chalmers.se]:

    First prize: $1000, free conference registration for two student team members, and the satisfaction of hearing the judges proclaim your programming language "the programming tool of choice for discriminating hackers."

    Second place language gets: "the consolation of hearing us proclaim your programming language "a fine programming tool for many applications." "

    So, I want to make sure this is clear: At the International Conference on Functional Programming, the judges had to get up a proclaim that "C++ is the programming tool of choice for discriminating hackers."

    I would've loved to be there. Anybody who was at ICFP care to comment?

  • Perspective from Judge's Prize team (Score:4, Interesting)

    by onesadcookie ( 621500 ) on Monday September 15, 2003 @12:29AM (#6961571) Homepage
    I was on the team that won the judge's prize, and whilst you can read our report at the link above, I have to say that for us, the key was the human, not the hardware or the program.

    The tracks we did well one were the ones that we were able to hand-drive accurately; the ones we did badly on were the ones where there were simply too many hard turns to make that feasible.

    Despite having a whole university lab full of computers we could have hijacked to run our program on, we only used a single computer for the actual optimizing.

    Also note that although our automatic optimizer was written in Dylan, the visualizer/racing game program was C++.

    If I were going to be controversial I would say that it all just goes to show that humans are better than computers and imperative languages are better than functional ones ;)
    • If I were going to be controversial I would say that it all just goes to show that humans are better than computers and imperative languages are better than functional ones ;)

      Oh yes. Too bad there is no Visual Fortran, it would have crushed the competition. :)

      See ya next year!

Slashdot Top Deals

Some people claim that the UNIX learning curve is steep, but at least you only have to climb it once.

Close