Contest - Traveller's Dilemma

**Daved** · 06-15-2007

Cool, thanks. I got working on this and it's really amazing how who wins really depends on the other entries.

I am going to enter, but I want to wait to submit my entry based on how many other people enter. I've got three different strategies that win at different times based on which other strategies I enter in my test tournament.

The more people that enter the better, because it is funner and more interesting. And as far as I can tell a complicated solution might not have a better chance than a simple one depending on the other entries.

**pianorain** · 06-15-2007

Originally Posted by Daved

Cool, thanks. I got working on this and it's really amazing how who wins really depends on the other entries.

Heh, it really is. At first it seems like such a simple thing, and yet the more you play with it, the more stuff seems to emerge. Simple programming dealing with challenging concepts.

Here's the code I'll be using to simulate. Please look it over; I'd rather not skew the contest in any way with a bug on my part.

**whiteflags** · 06-15-2007

I'm in. Good luck to the rest of you!

**h_howee** · 06-15-2007

I don't really understand this problem...
What's the advantage of picking 2?
How does picking 100 put you in a disadvantageous position? if you did, wouldn't you get a minimum of 98?

**whiteflags** · 06-15-2007

Originally Posted by h_howee

I don't really understand this problem...
What's the advantage of picking 2?
How does picking 100 put you in a disadvantageous position? if you did, wouldn't you get a minimum of 98?

The winner gets their pick plus a bonus in points, and the loser gets the other's pick minus the bonus value (as a penalty) in points. Therefore, picking the bottom number ensures points for yourself and your opponent will score low, and picking the top number is only safe while the opponent's guess is significantly large.

**Daved** · 06-15-2007

>> How does picking 100 put you in a disadvantageous position? if you did, wouldn't you get a minimum of 98?

You get a minimum of 2 less than the winning number, which is the smaller of the two numbers, so by picking 100, you will either get 100 (if the other person picked 100) or you'll get two less than the other numbers, whatever that is.

If you pick 100, it's impossible to get 98.

**Darryl** · 06-16-2007

I will enter, but I have a request also.

Can also add a void init(int number_of_players) function to the class?

**pianorain** · 06-16-2007

Originally Posted by Darryl

Can also add a void init(int number_of_players) function to the class?

I'm less inclined to change the interface since entries have already been submitted. Which reminds me of something I forgot to specify...please make sure your class implements a parameterless constructor, as that will be the one I call to populate the player vector. I'll add that to the rules also.

**Daved** · 06-16-2007

While you're adding to the rules you might consider disallowing the use of srand and just promise anybody who wants to use random numbers that srand will be seeded prior to the construction of their class.

**pianorain** · 06-16-2007

Originally Posted by Daved

While you're adding to the rules you might consider disallowing the use of srand and just promise anybody who wants to use random numbers that srand will be seeded prior to the construction of their class.

Ha...that'd be wonderfully devious.

Good call. Since I can't edit the post with the rules any more, be sure to check http://fluff.thejefffiles.com/coding/travellersdilemma/ for the most recent version. I'll put a link in my sig also.

**pianorain** · 06-18-2007

In addition to the above changes, I've prohibited the use of file I/O to persist data between simulations.

When you submit an entry, be sure to specify whether you'd like to have multiple copies of your entry in simulations that allow multiple entries or not. If you submit multiple entries, be sure to designate one as your primary entry.

[edit] The judging code contained a one-off bug resulting in incorrect round-robin schedules. The updated code can be found on the contest site.

[edit2] After running some testing with random number of turns per round, I tend to think we might want to use random number of turns per game instead.

Consider the case with three players: your code, a really challenging piece of code, and a fairly dumb piece of code (fortunately, nothing like that's been submitted yet). If your code plays the challenging code for an extended time, you and the challenging code may be tied. Then suppose that you play the dumb code for a short amount of time, while the challenging code plays the dumb code for a long amount of time. The challenging code would be able to pump more points out of the dumb code than you would.

Making it random per game eliminates any random bias.