Monday, October 7, 2013

Thursday, August 8, 2013

Prisoner's Dilemma Example and the Coalition Game

A great example of the Prisoner's Dilemma via kottke.org

 


Note Nick's insistence upon picking "Steal" right away, which put Ibraham in the position of taking a serious leap of faith. I was surprised by the ending.

I actually had a similar experience last night in my Negotiations class. We played "The Coalition Game," which went like so:

Three teams (A, B, and C) discuss how to split a pot of money. The pot of money can only be split between two teams (the coalition), leaving one team out. The pot of money to be split depends on which two teams form the coalition. The pot cannot be split evenly, and neither team can accept less than $0.01.

If Team A and Team B form a coalition, they split $20.

If Team A and Team C form a coalition, they split $16.

If Team B and Team C form a coalition, they split $12.

A coalition is formed only when two teams, after 9 rounds of one-on-one negotiations (order is below), agree on how to split the pot with one other team. After the final round of discussions, each team, individually and secretly, submits a slip of paper with their perceived agreement with another team. If none of the slips match, there is no coalition, and every one walks away with nothing.

Each team negotiates with one other team at a time, with the other team outside the room.

The order of negotiations is:

AB
AC
BC
(repeated twice more)

I was on Team A. We started off by offering Team B $13, with us taking $7.

We ended up outside the coalition at the end. It was a good exercise in trust and simple human greed.

Saturday, June 22, 2013

The Police - "Invisible Sun"

One of my favorite songs by The Police. The video is unavailable online in the U.S. RSS folks: click through if you can't see the video below.

Monday, June 10, 2013

Function Version: Determining Effective APY

In case you're more into functions:


function effective_apy_midpoint = effective_APY_midpoint(P,Y,n)

% Determines the effective annual yield (APY) given a principal amount, 
% a final amount, and number of years.

% Need to calculate r (APY)
% Use mid-point algorithm
% Formula is Y = P(1+r)^n

% Assume range of r from 0 to 5 (0 % to 300%)

r_min = 0;
r_max = 5;
current_guess = r_min;
Y_temp = P*(1+current_guess)^n;
num_guesses = 1;
while Y_temp ~= Y
    if (Y_temp > Y*0.9999) && (Y_temp < Y*1.0001)
        break
    end
    if Y_temp < Y
    next_guess = (current_guess + r_max)/2;
    else next_guess = (r_min + current_guess)/2;
    end
    Y_temp = P*(1+next_guess)^n;
    if Y_temp < Y
        r_min = next_guess;
    else r_max = next_guess;
    end
    current_guess = next_guess;
    num_guesses = num_guesses + 1;
    Y_temp = P*(1+current_guess)^n;
end
effective_apy_midpoint = current_guess;

MATLAB Script: Determining Effective APY

It's ugly, and I'm not sure if "midpoint algorithm" is the actual name of the algorithm. I remember doing this for my Numerical Methods course.



% Determines the effective annual yield (APY) given a principal amount, 
% a final amount, and number of years.
clear
clc
P = input('Enter principal (beginning) amount: ');
Y = input('Enter final (ending) amount: ');
n = input('Enter number of years: ');

% Need to calculate r (APY)
% Use mid-point algorithm
% Formula is Y = P(1+r)^n

% Assume range of r from 0 to 5 (0 % to 300%)

r_min = 0;
r_max = 5;
current_guess = r_min;
Y_temp = P*(1+current_guess)^n;
num_guesses = 1;
tic
while Y_temp ~= Y
    if (Y_temp > Y*0.9999) && (Y_temp < Y*1.0001)
        break
    end
    if Y_temp < Y
    next_guess = (current_guess + r_max)/2;
    else next_guess = (r_min + current_guess)/2;
    end
    Y_temp = P*(1+next_guess)^n;
    if Y_temp < Y
        r_min = next_guess;
    else r_max = next_guess;
    end
    current_guess = next_guess;
    num_guesses = num_guesses + 1;
    Y_temp = P*(1+current_guess)^n;
end
toc
r = current_guess;
effective_apy = r*100;
output_str = ['Effective APY = ',num2str(effective_apy),'%'];
num_guess_str = ['With ',num2str(num_guesses),' guesses.'];
disp(output_str)
disp(num_guess_str)

Wednesday, June 5, 2013

Product Idea: Restaurant-Provided Credit Card Roulette

As a male in his mid 20s, I have come across the "Credit Card Roulette" phenomenon a few times. Personally, I think it's better to just alternate picking up the check, but I can see the appeal of random chance when it comes to paying for a meal.

For those unfamiliar with the game, the basic form involves all diners in a party throwing their credit cards in a hat or similar container. A random credit card is drawn from the hat, sometimes by the server to maintain objectivity, and that card is used to pay for the entire meal. Usually this game is played at the end of the meal to prevent people from ordering more food than they normally would if they were paying for it themselves.

But that particular moral hazard got me thinking: what if restaurants provided a system that would let patrons play Credit Card Roulette before the meal began in exchange for a 10% discount off the entire meal? The restaurant would stand to gain, of course, if non-paying diners ordered more than 10% of what they would normally order.

I'm sure some clever game designer could figure out exactly what the interface to diners would be (kiosk at the table, smartphone app, etc.), but the concept would cater well to the gambling culture in America.


Benefits:

- At worst, the losing player would be treating their friends or colleagues to a meal they enjoyed. And most gamblers just like the adrenaline rush, right?

- Payment would be easier and faster if it's all going on one card (good for diners and the restaurant).

- Losing diners would be encouraged to return, thinking they wouldn't have to pay again because of the general misunderstanding of probability (see: the lottery). That's good for the restaurant.


Nobody really loses.

Tuesday, May 28, 2013

2013 Monaco Grand Prix Finishing Position vs. 2013 Driver Salary

I've only watched a few Formula One races, but I did manage to catch this weekend's Grand Prix de Monaco. Beautiful and exciting race, and only about 100 minutes long for those with things to do.

I did a quick regression on finishing position vs. 2013 driver salary. It's only one race, so there's bound to be some discrepancies (there were a couple accidents and one engine fire). However, the correlation is still quite moderate (R=0.613) andit makes the case for a more egalitarian approach to driver salaries. Alas: there's more to racing than just one race, and more to racing than, well: racing.

To note: one would expect a fairly strong downward-sloping curve if drivers were paid based on the results of just this one race.

I'll do another regression on 2013 World Series final results vs. salary.

Salary data (via Reddit) courtesy of Crash.net.



And when you log the salaries:




The best fit, as one may expect, is exponential:




Sunday, February 17, 2013

Video: A Case for Open Data in Transit

As a user of open data from the MBTA (I'm a big fan of NextBus), I can't agree more with the movement towards opening as much data as possible to developers for urban transit initiatives. If done right, it encourages expanded ridership and can serve to make the services more efficient.

I think O'Reilly's point in the video of government serving as a platform for private development is startlingly obvious and insightful.


Saturday, February 9, 2013

The Restaurant Service Auction Market

A recent story about a cheap pastor in St. Louis who got an Applebee’s server fired for uploading a copy of the pastor’s receipt (the pastor didn’t like the mandatory 18% tip for a group of 6, so she stiffed the server citing religious reasons) got me thinking about the Principal-Agent Problem again. I won’t dwell on it too much, but two quick things: 

First off, the obvious: doesn’t 10% seem a little low for a pastor? Why bother giving that figure, anyway? 

Secondly, punishing the server for a (disclosed and commonly applied) mandatory tip is a textbook example of the perils of the Principal-Agent Problem in the food service industry. The pastor should have gone directly to the manager to complain about the policy, but decided to take it out on the lowly server.

The fact that a religious figure was involved is a large part of why this story got out, but the fact of the matter is: the pastor should have taken out her frustration in another manner. It’s not like people blame her for bad weather events (a.k.a. Acts of God), right? 

Anyway, this sort of customer behavior can be avoided through a market approach. That is why, if I were to open a restaurant, I’d try something like this: 

  • All tips are set at a minimum of 15% and are pooled among all restaurant staff and there is no cap (i.e. a customer could bid for a 100% tip if they so desired)
  • Additional preferred treatment can be arranged by bidding (in units of % of the bill as total tip), such as: 
    • Personal food/drink recommendations
    • Faster service (this would be automatically controlled by the kitchen and bar – servers may game the system by holding up orders to appear like service to other tables is faster; customers can bid on when their meals or drinks come out) 
      • The estimated time of arrival of the meal or drink must be known to the customer for transparency. 
    • Requests for special occasions (birthdays, engagements, etc.) 
  • Customers are held to their promised tip amount unless the promised service at the time of the bid is not met (e.g. the food arrives a few minutes late) 
  • The price for a “bid for preferential treatment” is based on supply and demand. For instance, if it’s a busy Friday night with lots of people bidding, a 1% increase in tip won’t get you to the top of the list. 
    • Customers would only know if there is someone ahead of them and will be told by the system the current price (in % of tip) of a bid for a given request 
    • Someone who does not bid must be guaranteed some reasonable level of service. You might think of this as the “floor.” 
  • Standard quality must be maintained no matter how "rushed" a customer wants their food. This gets tricky if people want their food to be cooked faster than good quality would allow. This would need to be factored into resource constraints when telling the customer how quickly the food can be delivered to their table.


I'm not sure how well it would work (i.e. how long I'd stay in business), but it would be a good dining experiment.