kar: lets start.. we have a little more time for problem 4.
	I allocated more time to this since I thought this would need more time
	so maybe there's not as much time pressure.

deepti: what info do we have?

kar: you know everything, all the players, their speeds, their lanes etc.

bogdan: what exactly happens when two riders are in the same lane.

kar: the player behind gets slowed down

mss: maybe we can add some cost for a lane change.

kar: but the point of the game is to take advantage of the wind resistance.

eric: if the lane changes are instantaneous, cant a player move multiple
	lanes.

kar: can change only one lane in one time unit.

sasha: in real life, riders follow each other, but here they take the decision
	simultaneously

kar: yes.

peter: so you could change a lane while accelerating?

kar: yes

john: shouldnt we have a wider slipstream than only one lane..

hari: I think one should either accelerate or change lanes.

kar: rather than resolve the moves in sequence, we can collect them in sequence
	but still resolve them simultaneously.

andy: I would keep it as it is because its interesting this way.

kar: lets vote on the various changes:
	1) As is
	2) wide slipstream
	3) behind players see ahead lanechanges
	4) fewer lanes
	5) slipstream lasts an extra round
	6) Limited number of lane changes

peter: what about the sequential moves.

jeff: in case 3, 

zz: what if there's a risk involved in falling back

sasha: why dont we delay this decision until we've seen the players

kar: alf wanted some aggressive things.

alf: there's a risk in being behind.

anya: I think the risk in being behind is that you can be slowed down.

andy: two players which are ahead can block a player behind.

hari: can the players decelerate to zero speed.

kar: yes but the acc. dec. rates be bounded.

deepti: can all the team members be together at the starting of the race.

kar: no they'll be scattered randomly.

kar: lets start thinking about strategies.

kar: lets just think about what you'll do if you were running the race
	on your own.

john: I would think backwards. at the end all I want is for one of my
	riders to win and say the rest died.

kar: so how do you do this working backwards?

john: you'll definitely have 4 riders in line. the rider in front
	drops off first and so own.
	the tricky thing is to find the positions where your riders die.

mss: If I get more than one player across, the score would be the total.

jeff: resistance is propotional to v^{2.5}. in the last phase, the speed
	should be constant for minimum resistance.

eric: even if we solve this problem completely, there'll be lots of
	problems in the multiplayer game.

bogdan: it seems there'll be a closed form optimal solution.

miguel: there'll be some special behavior in the beginning, some
	steady in the middle and then something at the end.

zz: my intuition is that regardless of other teams, 

pj: I think there's a possibility of very close finishes.

anya: I think there are couple of things. in the last problem also,
	everyone said at the start that there's an optimal solution
	but it did not happen. Here also there are going to be many
	other teams counteracting each other.

lawrence: if a rider can install itself behind another team's line.

chris: because there is some randomness in the beginning, you cannot say
	that every race will end up the same way.

john: maybe you can recalculate the comlpex equation every step and
	win the race in all kinds of situations.

pv: I dont think that if one rider tags another player, can accelerate
	very fast at the end and win the race.

vipul: if you're riding on your own, calculate how much velocity you can
	go at to finish the race.

suv: this is exactly what I was thinking of. every 10 time units, you
	recalculate the parameters.

bb: I was thinking that if people are trying to follow you, dont spend too
	much time slowing other people down, since that would also slow you
	down.

deepti: you can save a certain amount of energy for a sprint at the end.