PORTFOLIO ARCHITECTURE

Problem Description



DOWNLOADS

version 4
Fixed minor bug where gambles would be linked multiple times. Each gamble was 'over-linked' the same number of times, so it didn't affect outcomes, thanfully.

version 3
GUI!! Not too fly, but something at least! Looks best with 6-8 players, which is what we will probably have in class. To run with gui, 'viz' arg needs to be true, eg. java Simulator data.txt 10000 true. In viz mode, the simulator waits till you hit the 'play' button before playing gambles and figuring your incomes.
Also added some new files that I used for testing:

version 2
Still no GUI, but updated with changes from class:

version 1  first draft, no gui

The download bundle contains:
The runnable files (the first three java files) will print 'usage' statements if u run them with no/unacceptable args.


DATA

Generate data by:
    java DataGen <nGambles> <outFile>
All three types of data (gamble probs & returns, attributes, links) are lumped together into one file. Each section is preceded by a line starting with '#' and then some text (directly lifted from the profblem webpage) describing the format. Here's an extract:
#gamble(gambleid, high return, high prob, medium return, med prob, low return, low prob)
000, 04.918, 0.268, 01.192, 0.206, 00.828, 0.526
001, 03.710, 0.388, 01.549, 0.209, 00.591, 0.403
...
...
#gambleatts(gambleid, A1, A2, A3, A4)
000, 1, 0, 0, 0
001, 1, 1, 1, 1
...
...
#link(gambleid, gambleid)
123, 125
123, 016
...
...
When reading in this data file, keep in mind:


RUNNING THE SIMULATOR
  usage: 
    java Simulator <dataFile> <port> <viz> [nRuns]
      dataFile  gambles,links,attrs
      port      for server
      viz       {true|false} - show gui
      nRuns     if viz=false, # games to keep server alive
You probably don't care about the gui for your development/testing.
So you probably want to run the Simulator with something like:
    java Simulator data.txt 10000 false 5
The last parameter tells the Simulator how long (in games) to keep the server alive before shutting down 'gracefully'. If you want to keep running tests without restarting the Simulator, you could run it with nRuns=100 or something. Just be aware that the server will stay alive till you send it 100 allocations, and you will have to kill the process if you want to stop it before then. In anticipation of gui needs, the Simulator does keep around all data from all games played, so it could theoretically run out of memory at some point, but that would take a while.


PROTOCOL

Connect to the server and send your name. You will get back OK.

Then send your first set of allocations as one line of nGambles space/comma separated decimals. As with the probabilities in the data, unless your allocations are exactly expressible in a finite number of decimal places, you will have to send approximations (with our game of 200 gambles, 5 or 6 decimal places should be sufficient to not warp your final results by any significant amount). The Simulator parses these finite precision allocations using java's Double.parseDouble(..) so anything that gets thru that is ok. After reading in your allocations, the Simulator normalizes them so that they sum to 1 (which conveniently is your initial starting 'wealth' in each game). If all goes smoothly, you will get back OK.

After assigning outcomes and calculating your income, you will be sent feedback in the form of one line containing your final wealth and nGambles space-separated outcomes drawn from {HI,MD,LO} (eg. "02.345 MD HI LO HI MD MD..."). The outcomes are in the order of gambleid and give no explicit indication of what order the gambles were played in or how the probabilities were adjusted based on the hidden attributes & links. If, over a series of games, you can figure out from this data which hidden attributes are favorable and which are unfavorable, you will probably start winning (final wealth > 2) a lot more often!!

After receiving the outcomes, send your next set of allocations.

If the Simulator can't handle something you send it, it should send back an error message saying ERR: <some reason>.

The RandomPlayer is a good place to take a quick glance to see how to follow the protocol. It's only a page of code, and fairly easy to understand. To run RandomPlayer:
   java RandomPlayer <host> <port> <name> <nGambles> <nRuns>