Implementing a multi-outcome DPM
j.niep...@googlemail.com
The market supports multiple outcomes in each market. I want to use
the DPM like David Pennock describes in his article (http://
dpennock.com/papers/pennock-ec-2004-dynamic-parimutuel.pdf ) in
chapter 5, where all the money is redistributed. I want to hide the
complexity from the user and let the marketmaker create book orders.
My idea is to create a book order for 10$ one for 30$ and one for 100$
(these are examples). Now I need to calculate the number of shares a
trader will get for that amount. My Problem is that the formula I need
is only provided for the binary case and my attempts to generalize
this formula failed so far.
Can anyone help me there?
Do you think its smart to create book orders for 10$ and calculate the
numer of shares or would it be better to create a book order for 10
shares and calculate the price (which seems even more difficult to
me)?
Thank you
Jörg
David Pennock
A few thoughts:
* Though in some ways I'd love to see you use DPM, you might also
consider Hanson's LMSR, described from an implementation point of view here:
http://blog.oddhead.com/2006/10/30/implementing-hansons-market-maker/
* You definitely don't want to use the "money ratio price function"
described in the 2004 paper. You want to use the "share ratio price
function" described at a high level in this paper:
http://dpennock.com/papers/mangold-ieee-computer-2005-buzz-game.pdf
I can also send you something with more detail if you decide to go this
route.
regards,
Dave
Chris Hibbert
I think this is the wrong level of detail to start with. The two
important questions are the algorithms.
If Pennock doesn't know of a multi-outcome parimutuel algorithm (and
doesn't think the derivation is obvious) then this is one interesting
problem. You have to start from first principals: what constraints does
the DPM enforce, and what are the corresponding invariants for the
multi-outcome case? If you think through this carefully, you'll either
find that the situation is over-constrained or under-constrained. In
one case, you have to exercise some design sense to choose a better
definition of the problem that you can derive a solution for. In the
other case, your design sense gets exercised in order to decide what
other features of the situation you can exploit in order to produce the
most fun, challenge, or fairness.
The other algorithmic challenge you have to address before it makes any
sense to talk about writing software is what you want the market maker
to do. Hanson's LMSR market maker is guaranteed to increase liquidity
while losing a bounded amount of money. That's one possibility, but you
have to figure out how to do that in conjunction with the multi-outcome
DPM rules you invent. You clearly want to have a budget constraint,
since otherwise your market maker will be a money pump to sophisticated
traders. Hanson described a family of algorithms that follow different
rules, each of which has a different effect on trading volume and
prices. Discovering a rule that will allow a market maker to operate
without losing an unbounded amount of money will require some serious
thinking.
Once you have the algorithms, deriving prices from volume and volume
from pricing will be equally easy. The more interesting question driven
by the UI is whether the users will be more used to dealing in money
amounts or share quantities that aren't rounded to whole numbers. I've
seen some markets that only deal in whole shares, but none that only
deal in whole dollar amounts. But most markets handle fractional shares
as well, so it's not really a hard constraint.
Chris
--
It is easy to turn an aquarium into fish soup, but not so
easy to turn fish soup back into an aquarium.
-- Lech Walesa on reverting to a market economy.
Chris Hibbert
hib...@mydruthers.com
http://mydruthers.com