Very interesting article! I would like to know how much time was spent on developing the bot.
Most of the development was done after putting my son to bed and before collapsing of exhaustion at 3am.
21–30 of 39 posts
Very interesting article! I would like to know how much time was spent on developing the bot.
Most of the development was done after putting my son to bed and before collapsing of exhaustion at 3am.
The interesting subtext of this competition is that to an extremely good approximation, everyone who was interested enough to write a competitive entry used C/C++, even though the organizers went to great lengths to support as many languages as possible (e.g. Haskell, Scheme, etc.) This is with a small self-contained problem where performance wasn't a main difference between entries, and fast prototyping and experime…
I did have some problems throughout the contest with my choice of C++ -- in fact without Valgrind, my entry may never have run correctly. (Turns out one of my algorithms was "escaping" off the border of the map and scribbling in RAM) But hey, I've been dealing with problems like that for more years than I care to count right now.
technology can support the players affect the soles of the feet and legs friction weight, these href="wholesale" rel="nofollow">http://www.shoesgroups.com/reebokanswer-c-70.html>wholes... reebok answer shoes are the perfect combination of speed
and passion. This wholesale reebok answer shoe has launched an all-star red, black and the world, these two limited edition
colors. Series, as fans should not miss the fine, We are free shippmtand a week to your door.004
Earlier quoted context omitted.
Surely if language X is blub and language Y isn't then Y beats X if all else is even. Surely everyone experienced at these competitions would quickly figure out that lisp et al are huge competitive advantages, and everyone would quickly switch. From what I've seen working with some living legends in computer science the language makes almost no difference in actual productivity, it's just personal preference. It's ju…
"Surely everyone experienced at these competitions would quickly figure out that lisp et al are huge competitive advantages, and everyone would quickly switch." You missed the part where I pointed out that current major competitions don't accept arbitrary languages. That's the key point of my post. All else is not even. If they did accept arbitrary languages I would accept your logic, given sufficient time for networ…
In this competition, if you wanted to use another language, you just needed to make a starter package (a stupid bot) and some instructions to get the compiler working on their end. So in this competition, arbitrary languages where accepted.
Earlier quoted context omitted.
That is interesting indeed. If you go on to page 2 of the rankings* you can see that there were indeed a large number of Haskell, Python, Lisp and Ruby entries, but the top 100 (and especially the top 25) are totally dominated by C++. The other thing I find interesting is the lack of Java entries. Java is as widely-known as C++, but there's only one Java entry in the top 100, and even in the top 200 Java is only abou…
The problem with Java was that it was impossible to get it running fast enough. You had 1 second of thinking time, but with Java you could barely access 0.05s, while compiled languages like C/C++ or even C# could easily use 0.95s without having any timeouts (which leads to disqualification).
The interesting subtext of this competition is that to an extremely good approximation, everyone who was interested enough to write a competitive entry used C/C++, even though the organizers went to great lengths to support as many languages as possible (e.g. Haskell, Scheme, etc.) This is with a small self-contained problem where performance wasn't a main difference between entries, and fast prototyping and experime…
You know, I didn't even once mention the language I used. Realtime constraints and searching speed were the driving factor here; you have to return a move in under one second. I didn't want to risk GC pauses, and I'm not good enough with Haskell to guarantee I'm writing fast code. Otherwise I probably would have used something else, but I don't consider it all that important. Really, there wasn't anything too complic…
The interesting subtext of this competition is that to an extremely good approximation, everyone who was interested enough to write a competitive entry used C/C++, even though the organizers went to great lengths to support as many languages as possible (e.g. Haskell, Scheme, etc.) This is with a small self-contained problem where performance wasn't a main difference between entries, and fast prototyping and experime…
That is interesting indeed. If you go on to page 2 of the rankings* you can see that there were indeed a large number of Haskell, Python, Lisp and Ruby entries, but the top 100 (and especially the top 25) are totally dominated by C++. The other thing I find interesting is the lack of Java entries. Java is as widely-known as C++, but there's only one Java entry in the top 100, and even in the top 200 Java is only abou…
The interesting subtext of this competition is that to an extremely good approximation, everyone who was interested enough to write a competitive entry used C/C++, even though the organizers went to great lengths to support as many languages as possible (e.g. Haskell, Scheme, etc.) This is with a small self-contained problem where performance wasn't a main difference between entries, and fast prototyping and experime…
You know, I didn't even once mention the language I used. Realtime constraints and searching speed were the driving factor here; you have to return a move in under one second. I didn't want to risk GC pauses, and I'm not good enough with Haskell to guarantee I'm writing fast code. Otherwise I probably would have used something else, but I don't consider it all that important. Really, there wasn't anything too complic…
:D
http://blog.danielwellman.com/2008/10/real-life-tron-on-an-a...
For example the expected value of moving up and left should be the same as the the expected value of moving left then up?
That would cut down the search space some. Of course it adds memory overheads.
You could also memoize the voronoi heuristic if that takes a long time to compute.