1. Applications of Automated Mechanism Design
Marita Nowotka
Mateusz Kopeć
Introduction to Electronic Commerce
Hello everyone and welcome to our presentation. I am Mateusz and this is Marita and we're going to talk about automated mechanism design, basing on the article of Vincent Conitzer and Tomas Sandholm.

2. Outline Introduction Automated Mechanism Design Divorce settlement
Optimal Auctions
Public goods problems
Scalability
This presentation is going to be structured as follows: First, I'll shortly introduce the topic of mechanism design and automated mechanism design. After that we'll present some examples of mechanisms created using automatical methods. The last part of the presentation is going to be the discussion about real possibilities of using described techinques to solve real life problems.

3. Introduction What is a mechanism? A game of selfish agents,
which is created in such a way, that desirable outcome is reached.
Agent B
Likes
apples
oranges
Agent A
A gets 1 apple,
B gets 1 apple
A gets 3 apples,
B gets 1 orange
A gets 2 apples,
B gets 2 oranges
A gets 1
orange,
So what are we designing, what is a mechanism? Well, it's simply a game of selfish agents. You can see an example of a game of two agents. Each of them can have a preference: can like oranges or apples. This are the types of agents, for example agent A can be of an apple liking type or an orange liking type. In the game, each player reveals his type and based on this the outcome of the game is chosen.
All of the difficulty of desining such games is that we want a desirable outcome to be chosen even though the agents behave selfishly.

4. Introduction Tradition: designing general mechanisms.
Idea: create software to make solutions for particular problems!
Solution: Generate specification of the problem as integer/linear program and solve it. (with CPLEX 8.0)
Traditionally, the focus in mechanism design has been on designing mechanisms that are appropriate for a range of settings. (for example VCG). The problem is that these solutions are very often not satisfactory, they are not sufficiently flexible.
The key idea of presented paper was to create a program which can find optimal solutions for particular problems.
The authors implemented and tested a system which formulates given problem as as integer or linear program and solves it, using CPLEX library.

5. Automated Mechanism Design
Mechanism design setting:
Set of outcomes
Set of agents
Sets of types of each agent (with probabilities)
Utility function
Agent B
Likes
apples
oranges
Agent A
A gets 1 apple,
B gets 1 apple
A gets 3 apples,
B gets 1 orange
A gets 2 apples,
B gets 2 oranges
A gets 1
orange,
These are the settings of mechanism design, which are set as an input to automatic mechanism design algorithm. As an output we will receive an optimal solution for given settings.
First of all, we need to specify obvious things such as the set of possible outcomes, set of agents. We also need possible types of each agent, together with the probabilities of them. Another needed thing is the utility function, simply telling how much each agent values each outcome.
How much each agent is happy with each outcome.
tbc.

6. Automated Mechanism Design
Mechanism design setting ctd:
Description of possible tools:
Are payments possible?
Is randomization possible?
An objective function we want to maximize:
Sum of payments (revenue of seller)?
Sum of utilities (social welfare)?
tbc..
There are also another parameters, such as description of possible tools of the designer of the mechanism: are the payments possible and is randomisation possible. Randomisation simply means that produced mechanism can have some randomness in giving the final outcome of the auction. I will show an example in a minute.
Morover, we need to tell the software which objective function we want to maximize. Do we need our mechanism to maximize in the resulting outcome sum of payemnents made by participants, or sum of their utilities?

7. Automated Mechanism Design
Truthfullness of agents:
Dominant Strategies (DS)
Bayes-Nash equilibrium (BNE)
Individual Rationality (IR):
Ex post (participation knowing each agent's type)
Ex interim (participation knowing only own type)
The last two parameters are as follows. First, we always want the agents to tell the truth, that means we want them to have no profit while lying about their type. There are two possibilites: we may want a mechanism in dominant strategies, which means that an agent never would like to lie, even when he knows the types of other agents. Second possibility is weaker: we may want a mechanism when an agent never would like to lie when he knows only his own type. And this is called Bayes nash equilibrium.
Last parameter of mechanism design is the IR constraint. It means that an agent won't leave the game. Again two types of specification are possible: ex post, when he knows everything, and ex interim, when he knows only his own type.

8. Divorce settlement Agents: Item: a painting
Husband
Wife
Item: a painting
Two types of valuation of it:
High (with probability 0.2)
Low (with probability 0.8)
Get the painting
Other gets
paitning
Joint ownership
Burn it!
Low 2 1
-10
High
100 50
Finally I can show you some examples of mechanism automatically created using described software. We have a sad situation of a divorce, the agents therefore are: a husband and a wife. The problematic thing is that they jointly own a painting and must somehow decide what to do with it after the divorce. Both husband and wife can be one of two types: they can value the painting high (with probability 0.2) and low (with probability 0.8).
There are 4 possible outcomes of this situation. The painting can go either to husband or wife, can be left as a joined ownership and hunged in a musem or be burned!
This table presents the utilites of agents, that means how much they value each possible outcome, with respect to their type.

9. Benevolent arbitrator
- No payments
- Social welfare
Husband_Low
Husband_High
Wife_Low
Husband gets it
Wife_High
- DS
- No randomisation
Husband_Low
Husband_High
Wife_Low
Joint ownership
Husband gets it
Wife_High
Wife gets it
Burn!
- BNE
- No randomisation
If we choose to design a mechanism o benevolent arbitrator, without payments and maximisation of social welfare, without randomisation and with domiant strategies, we will get following table. The husband gets the painting always and this is optimal – we cannot have better algorithm with this settings.
Hwoever, if we only require BNE, this means a player wouldn't like to lie if he knows only his type, we will get better mechanism. As you can see, when both report high, the painting is burned! This seems unoptimal, but is needed to get agents tell the truth.
Another example is when we allow randomisation – this time mechanism is not deterministic. 45% chance of burning the painting is sufficient to prevent agents from lying about their types.
Husband_Low
Husband_High
Wife_Low
57%: husband,
43%: wife
100%: husband
Wife_High
100%: wife
45%: burn,
55%: husband
- BNE
- Randomisation
allowed

10. Benevolent arbitrator with payments
- Social welfare
- No randomisation
- DS
Husband_Low
Husband_High
Wife_Low
Husband gets it,
Husband pays 0,
Wife pays 0
Wife_High
Wife gets it,
Wife pays 2
Now lets allow payments, but have still a benevolent arbitrator, who wants to maximize social welfare, not his income. With implementation in DS without randomisation we get the following table.
The allocation of painting is now always optimal, but we have a price for that – now sometimes the wife has to pay money. This is required to remove the possibility of her reporting falsely about her high type.

11. Greedy arbitrator - With payments - Sum of payments maximization
- No randomisation
- DS
- Ex post IR
Husband_Low
Husband_High
Wife_Low
Burn!
Husband pays -10,
Wife pays -10
Husband gets it,
Husband pays 100,
Wife pays 0
Wife_High
Wife gets it,
Husband pays 0,
Wife pays 100
Now the last example with divorce issue. Lets consider a greedy arbitrator, who wants to maximise his income. We now need ex post IR, which means that neither wife nor husband won't leave the game, even when they know the other's type. Wihout randomization and with dominant strategies we get the following:
Now the item is burned when they both report heir low types! As for the payment, the arbitrator is now able to extract all of utility of the agent, who gets the painting. But in the low-low case, probably he must compensate the parties for the loss.

12. An optimal 2-bidder, 2-item combinatorial auctionLL LH HL HH
0, 0
0, 2
2, 0
2, 2
0, 1
1, 2
2, 1
1, 0
1, 1
Bidders have one of {Low, High} preferences regarding each item
Maximize seller revenue
BNE
Ex interim IR
Expected revenue from this mechanism:
Expected revenue from the VCG mechanism:

13. Public goods problem – bridge building
Bridge cost: 6
Agent's types: {Low, High}
We want to minimize money burning
Randomised mechanism
Probability Low
Value Low
Probability High
Value High
Agent 1
0.4 1
0.6 10
Agent 2 2 11

14. Bridge building, approach 1
Bridge cost: 6
Agent's types: {Low, High}
No money burning DS
Ex post IR
Probability of building a bridge
Low
High
0.67 1
Payment function
Low
High
0, 0
0.67, 3.33
4, 2

15. Bridge building, approach 2
The same task
Changed requirements from DS to BNE
Now, whenever anybody wants a bridge, it will be built
No money burning
BNE
Ex post IR
Probability of building a bridge
Low
High 1
Payment function
Low
High
0, 0
0, 6
4, 2
0.67, 5.33

16. Bridge and/or boat building
2 agents
Agents preferences: {None, Boat, Bridge Boat and Bridge}
Avoid money burning
Randomised mechanism DS
Ex post IR

17. Bridge and/or boat building
Outcome function
None
Boat
Bridge
Either
(1,0,0,0)
(0,1,0,0)
(0.5,0.5,0,0)
(0,0.5,0,0.5)
(0,0,1,0)
None
Boat
Bridge
Either
(1,0,0,0)
(0,1,0,0)
(0.5,0.5,0,0)
(0,0.5,0,0.5)
(0,0,1,0)
Payment function
None
Boat
Bridge
Either
0,0
0,1
0.5,0
1,1

18. Scalability
#agents
D/DS
R/DS
D/BNE
R/BNE 2
.02
.00 3
.04
.05
.01 4
8.32
1.32
1.68
.06 5
709.85
48.19
10.47
.52
Allowing for randomness in the mechanism leads us from NP- completeness to solvability in polynomial time. (Compare columns D/DS and R/DS).

19. Scalability II
IR constraint
D/DS
R/DS
D/BNE
R/BNE
None
8.32
1.32
1.68
.06
Ex post
8.20
1.38
1.67
.12
Ex interim
8.11
1.42
1.65
.11
The impact of IR constraints on runtime is entirely negligible.

20. Scalability III
Objective
D/DS
R/DS
D/BNE
R/BNE
SW(1)
8.20
1.38
1.67
.12
SW(2)
.41
.14
.92
.10
SW(3)
7.98
.51
4.44 π -
1.89
84.66
3.47
SW = social welfare (1) without payments, (2) with payments that are not taken into account in social welfare calculations, (3) with payments that are taken into account in social welfare calculations
π = payment maximization.
Payment maximization appears to be much harder than social welfare maximization.