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:

NotSoRandomPlayer.java - randomly allocates only to gambles with certain attrs. run with no args for usage statement
multiplayersim.sh - script to simulate a multiplayer game. in case u want to see what the gui will look like at run-time

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

each gamble's expected return = 2
balanced attribute distribution in data
no transitivity of links

version 1 first draft, no gui

The download bundle contains:

arch.html - this file
source code
- DataGen.java - generates data
- Simulator.java - runs the game
- RandomPlayer.java - protocol demo
- Server.java - used by the Simulator, not directly runnable
compiled class files for the above

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:

Gamble ids run from 0...(nGambles-1)
Numbers may have leading 0s, especially the first gamble's id, which is 000
Probabilities are quoted to limited precision and may add up to .999 or 1.001 or whatever. However you read them in, once you translate them to numeric quantities rather than characters, normalize them (make them sum to exactly 1). It's easy enough, and the Simulator is going to have to do that with your allocations when you send them in, so let's all get used to normalizing decimal data.
Gamble links are symmetric. So if '005,002' is a link-pair, whichever one is played first could influence the outcome of the second.
Gamble links are stated as pairs, but a gamble may be linked to more than 1 other gamble. As it stands now, no gamble is linked to more than 3 others, but this may change.

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>