Live data from Hacker News

Google AI Challenge: Winner post-mortem and source code

a1k0n.net

21–30 of 39 posts

Re: Google AI Challenge: Winner post-mortem and source code

#22

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 complicated data-structure-wise to do. In fact it does next to no dynamic allocation. I wanted to use destructive updates for speed when doing a backtracking search on a map. The hard part was just implementing various recursive algorithms, and C++ didn't really get in the way of doing it except that it would have been nice to have multiple return values.

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.

Re: Google AI Challenge: Winner post-mortem and source code

#23
Laboratory Evaluation, wholesale" rel="nofollow">http://www.shoesgroups.com/reebokanswer-c-70.html>wholes... reebok answershoes, pump

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

Re: Google AI Challenge: Winner post-mortem and source code

#24
post #17

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…

"You missed the part where I pointed out that current major competitions don't accept arbitrary languages."

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.

Re: Google AI Challenge: Winner post-mortem and source code

#25
post #5

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).

My impression is that as long as you can ignore startup time, Java in general is pretty close to C++ and definitely much faster that Python. I am surprised this would be a problem with Java and not with Python. Did anyone had the same problem with Python?

Re: Google AI Challenge: Winner post-mortem and source code

#26
post #22

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…

[deleted]

Re: Google AI Challenge: Winner post-mortem and source code

#28
post #5

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…

It might have something to do with the blatant warning on the entry page telling you not to use Java due to some mysterious problem with it and their sandbox.

Re: Google AI Challenge: Winner post-mortem and source code

#29
post #22

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…

> 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.

:D

http://blog.danielwellman.com/2008/10/real-life-tron-on-an-a...

Re: Google AI Challenge: Winner post-mortem and source code

#30
Did you do any sort of memoization of the minmax evaluation?

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.

Post reply on HN