Friday, February 17, 2012

Performance Versus "The Line"

As I've mentioned earlier, I use my models to bet (in some theoretical sense) against the "the line".  Typically I bet the games where my model differs significantly from the line (e.g., >4 points or so).  As I've documented here, I have a number of different models, all of which have around the same performance (~11 points RMSE).

In the past I've usually averaged the predictions of these models for betting purposes, but for some time I've wondered whether they all perform equally well against the line.  Although they all have similar errors, it's possible that some of the models error more consistently to the winning side of the line.  To test this, I gathered three seasons worth of Vegas closing line data (about 7700 games) and tested each model for how often its predictions were correct versus the line.  (The predictor is "correct" if it would make a winning bet given the line.)  I also looked at each predictor's error versus the line (i.e., how accurately it predicted the line).

  ModelPerformance
vs. Line
Error vs. Line 
TrueSkill49.89%3.75
Govan49.28%3.49
BGD49.58%3.51
Base Statistical50.12%4.34
Statistical w/ Derived 50.15%4.34
All 52.00%3.49
All (Difference > 2)53.15%

The "All" model here is a linear predictor using all the inputs to TrueSkill, Govan, BGD and Statistics w/ Derived.  (I also tested some voting models, but they all under-perform the Statistical/All models.)

There are a couple of interesting results.

Most noticeably, the "All" predictor is at break-even versus the line.  (Due to "house cut" on sports bets, you need to win about 52% of your bets to break even.)  If we restrict ourselves to bets where the predictor differs from the line by at least two points, performance moves into (barely) positive territory.  This is very good performance; the best predictors tracked at The Prediction Tracker do not even break 50%.  (Furthermore, I am using the "closing" line, which is a tougher measure [by about one point] than the opening line used at the Prediction Tracker.)

It's also intriguing that TrueSkill/Govan/BGD all underperform the line but track it noticeably better than the statistical predictor.  This suggests to me that the line is set not by wily veteran gamblers in the smoky back rooms, but by a computer program using some kind of team strength measure.

A (possibly interesting) side-note:  All models that under-perform the line are going to fall into the seemingly miniscule range of 48-52%.  (If a model performs worse than 48% against the line, we would simply bet against the model.)  Pick any crazy model you like -- "Always bet the home team," "Always bet on the team whose trainer's name is first alphabetically," etc. -- and the performance is almost certainly going to fall in that 48-52% range against the line.  (If it doesn't, you've found the key to beating Vegas!)

Friday, February 10, 2012

The Continued (Slow) Pursuit of Statistical Prediction (Part III)

As promised last time, we'll now look at a different type of derived statistic. We're going to look at statistics which are the ratio between the two teams of the same base statistic, e.g.,

(Ave # of offensive rebounds for the home team / Ave # of offensive rebounds for the away team)

The idea here is that it may be more predictive to look at the relative strengths of the teams rather than the absolute strengths. 

The first statistics I want to try this upon are the strength measures like TrueSkill and RPI. Suppose that Syracuse, with an RPI of 0.6823, plays Missouri, with an RPI of 0.6234, and the same night UCF, with an RPI of 0.5723 plays Oregon State with an RPI of 0.516.  Would we expect the same outcome in those games?  In both cases, the better team is about 0.06 better in RPI.  But Syracuse is about 10% better than Missouri, while UCF is about 12% better than OSU.  If it's the relative strength that matters, we would expect UCF to win (on average) by more than Syracuse.

To test this out, I generated the relative strengths for measures like TrueSkill and ran them through my testing setup.  In every case, the relative strengths had no predictive value above and beyond the value of the absolute strengths.  And when the relative strengths alone were used for prediction, they underperformed the absolutes used alone.

I then did the same thing for the statistical attributes like offensive rebounding and got the same result.  The relative strengths of the two teams provided no additional predictive accuracy.

I find this result fairly intriguing.  My strong intuition was that at least a portion of the game outcome would be better explained by the relative strengths of the two teams. It's hard to believe that Syracuse should win its game against Missouri by more points simply because they're both stronger teams than UCF and OSU.  But (as has often proven to be the case!) my intuition was just wrong, and relative strength is much less important than I would guess.

Friday, February 3, 2012

The Continued (Slow) Pursuit of Statistical Prediction (Part II)

Continuing on from last time, I had set up the infrastructure to allow me to easily test the value of derived variables in statistical prediction.  Before testing any of these derived variables, we need a baseline.  In this case, the baseline is the performance of a linear regression using all the base variables.  I don't know that I've ever documented the base variables, but they are basically all that can be created from the full game statistics available at Yahoo! Sports.  These are averaged by game, so for example one of the base statistics is "Average free throw attempts per game."  I also have the capability to average statistics by possession (e.g., "Average free throw attempts per possession" but unlike some other researchers, I've never found per possession averages to be any more useful than per game averages, so I generally don't produce them.

For most statistics, I also produce the average for the team's opponents.  So to continue the example above, I produce "Average free throws per game for this team's opponents."  I also produce a small number of simple derived statistics, such as "Average Margin of Victory (MOV)", and winning percentages at home and on the road.

When we get to predicting game outcomes, of course we have all of these statistics for both the home and the away team.  (And that home/road distinction is important, obviously.)  If we use all these base statistics to create a linear regression, we get the following performance:

  Predictor    % Correct    MOV Error  
Base Statistical Predictor72.3%11.10

This is the same performance I have reported earlier, and tracks fairly well with the best performance from the predictors based upon strength ratings.

Now we want to augment that predictor with derived statistics to see if they offer any performance improvement.  As mentioned last time, we have 1200 derived statistics, so we have to do some feature selection to thin that crop for testing. 

One possibility (as discussed here) is to build a decision tree, and use the features identified in the tree.  If we do that (and force the tree to be small), we identify these derived features as important:

  1. The home team's average margin of victory per possession over the overall winning percentage
  2. The away team's average number of field goals made by opponents over average score
  3. The home team's average assists by opponents over the field goals made
  4. The home teams average MOV per game over the home winning percentage
That is, you'd have to admit, quite a goulash of statistics.  I can probably come up with some rationale about some of those, but I won't bother.  All I really care about is whether they will improve my predictive accuracy.

To test that, I add those statistics to my base statistics and re-run the linear regression.  In this case, what I find is that while some of the derived statistics are identified as having high value by the linear regression, the overall performance does not improve.

There are other methods for feature selection, of course.  RapidMiner has an extension focused solely on feature extension.  This offers a variety of approaches, including selecting based on Maximum Relevance, Correlation-Based Feature Selection, and Recursive Conditional Correlation Weighting.  All of these methods identified "important" derived statistics, but none produced a set of features that out-performed the base set.

A final approach is a brute force approach called forward search.  In this approach, we start with the base set of statistics, add each of the derived statistics in turn, and test each combination.  If any of those combinations improve on the base set, we pick the best combination and repeat the process.  We continue this way until we can find no further improvement.

There are a couple of advantages to this approach.  First, there's no guessing about what features will be useful -- instead we're actually running a full test every time and determining whether a feature is useful or not.  Second, we're testing all combinations in our search space, so we know we'll find the best combination.  The caveat here is that we assume that improvement is monotonic with regards to adding features.  If the best feature set is "A, B, C" then we're assuming we can find that by adding A first (because it offers the most improvement at the first step), then B to that, and so on.  That isn't always true, but in this case it seems a reasonable assumption.

The big drawback of this approach is that it is very expensive.  We have to try lots of combinations of features, and we have to run a full test for each combination.  In this case, the forward search took about 54 hours to complete -- and since I had to run it several times because of errors or tweaks to the process in ended up taking about a solid week of computer time.

In the end, the forward search identified ten derived features, with this performance:

  Predictor    % Correct    MOV Error  
Base Statistical Predictor72.3%11.10
w/ Forward Search Features74.0%10.73

This is a fairly significant improvement.  The most important derived features in the resulting model were:
  1. The away team's opponent scoring average over the away team's winning percentage.
  2. The away team's offensive rebounding average over the away team's # of field goals attempted
  3. The away team's scoring average over the away team's winning percentage
  4. The away team's opponent treys attempted over the away team's rebounds
The ten statistics were actually evenly divided between home team statistics and away team statistics, but it turned out that the most significant five were all the away team statistics.

I'll leave it to the reader to contemplate the meaning of these statistics, but there are some interesting suggestions here.  The first and third statistics seem to be saying something about whether the away team is winning games through defense or offense.  The second and fourth statistics seem to be saying something about rebounding efficiency, and perhaps about whether the team is good at getting "long" rebounds.  (The statistics for the home team are completely different, by the way.)

Next time I'll begin looking at a different set of derived statistics.

Friday, January 20, 2012

The Continued (Slow) Pursuit of Statistical Prediction

When we last met on this topic, I was inspired by the Four Factors to look at derived statistics created from the ratio of two existing statistics, e.g.,


Offensive Balance = (# 3-Pt Attempts) / (# FG Attempts)

My previous work in this area has convinced me of the value of looking at all possibilities, no matter how non-intuitive, my approach was to look exhaustively at all the possible ratios between the ~35 base statistics.  That leads to some crazy statistics such as:

(Average # of fouls per possession by the home team's previous opponents) / 
    (Average offensive rebounds per game by the home team in previous games)

There turn out to be a number of difficulties with this approach.  (Perhaps not unsurprisingly, although crazy nonsensical statistics are not one of them.)

First, it's a lot of work just to generate the 1060 derived statistics.  (Only 1060 because I avoided inverse ratios, and avoided "cross-ratios" between the two teams.)  Initially I was generating a subset of these from within the Lisp code that pre-processes the game data.  That was painful to set up and slow to execute.  Eventually I discovered a way to generate the derived statistics within RapidMiner. I was able to drive this from a data file, so I wrote a small Lisp program to generate the data file that RapidMiner could use to construct all 1060 derived statistics.

Second, this amount of data tended to overwhelm my tools.  With the derived attributes, each game has about 1200 attributes total.  My training corpus has about 12K games.  The combination tended to break most of the data modeling features of RapidMiner, usually by overwhelming the memory capacity of Java.  Even when the software was capable of handling the data volume, operations like a linear regression might take hours (or days!) to complete, so testing and experimenting was laborious at best.

One way to reduce this problem is to thin the dataset, by testing on (say) a tenth of the full corpus.  But that introduced a new problem: overfitting.  If I used (say) a tenth of the data, I had about 1200 games in my test set -- just about the same number of test games as attributes.  The result of that is almost invariably a very specific model that does extremely well on the test data and very poorly on any other data.

Another approach is to thin the attributes.  This is the feature selection problem.  The idea is select the best (or at least some reasonably good) set of features for a model.  The stupid (but foolproof) way to do this is to try every possible combination of features, and select the best combination.  But of course that's infeasible in many cases (such as mine), so a variety of alternative approaches have been created.  RapidMiner has some built-in capabilities for feature selection, and there's a nice extension to add more feature selection capabilities here.

I experimented with a variety of different feature selection approaches.  I was hopeful that different approaches would show overlap and help identify derived attributes that were important, but for the most part that did not happen.  However, taking all the attributes recommended by any of the feature selection approaches did give me a more reasonable sized population of derived statistics to test.

More on this topic next time.

Tuesday, January 17, 2012

Basketball Season Underway

I spent the last few days scraping game data, dusting off code and generally getting the basketball predictor back online.  The current version of the predictor uses an average of 4 linear regressions.  These models are based upon: (1) the Govan rating, (2) the TrueSkill rating, (3) a Batch Gradient Descent (BGD) rating, and (4) a rating based on a wide variety of statistical measures (such as "offensive rebounds per possession").   Individually, each of these models has a RMSE of less than 11 on my test corpus.   Unfortunately, they're all highly correlated, so the combined model doesn't do any better than the best of the underlying models.  Currently it has an RMSE of 10.79 on my test corpus.

During the season I compare the model predictions against the line and "bet" games where the prediction differs significantly from the line.  "Significantly" is a relative term.  When I first started doing this, my model often differed from the line by 10 points or more.  As the model has improved, those differences have narrowed considerably.  (As would be expected.  The line is usually the best predictor.)  In my testing so far this year, I've only seen a difference of more than 5 points once.  There is some good mathematical work on sizing wagers based upon bankroll, perceived advantage, etc., but I've gone to a simple approach of betting $10 with an advantage of < 5 points and $20 with an advantage of >5 points.  (Adopted after the 1/14 games shown below.)

Here are the games the model has "bet" so far (no real money was harmed):

Date Home            Score Away                   Score MOV Line Pred Adv Risk Win Result Won v.Line
1/14 Tennessee St. 52 SIU Edwardsville 49 3 16 8.8 -7.2 20 17.39 17.39 1 1
1/14 LA Lafayette 87 Florida Intl. 81 6 10 5.1 -4.9 20 19.05 19.05 1 1
1/14 Murray St. 81 Tennessee Tech 73 8 12 16.5 4.5 20 18.18 -20 1 0
1/14 Houston 55 Memphis 89 -34 -8.5 -4.2 4.3 20 17.39 -20 1 0
1/15 Ohio St. 80 Indiana 63 17 13.5 9.1 -4.4 10 9.09 -10 1 0
1/15 Bradley 78 Northern Iowa 67 11 -10 -7.2 2.8 10 8.70 8.70 0 1
1/15 USC 47 UCLA 66 -19 2 1.5 -0.5 10 9.09 9.09 0 1
1/16 Syracuse 71 Pittsburgh 63 8 13.5 17.3 3.8 10 9.09 -10 1 0

So far this season the model is 50% against the line (and subsequently down about $5) and 75% picking the correct outcome.  The (evolving) model picked 38 games last year, and over the two seasons so far is at a 63% win percentage and 60% versus the line (+$133).  Both are probably short-term aberrations -- the model has a 74% win percentage when tested against my corpus of 12K games.

I won't generally be posting predictions, but I will try to summarize the model's performance a few times during the season, as I'm sure it makes for interesting reading :-).

Wednesday, January 11, 2012

Football Wrap-Up

A quick wrap-up of my performance predicting NCAA football.

This experiment started around the beginning of October, when some friends challenged me to use my program to predict football against a couple of other guys.  In addition to predicting games, we would be "betting" against the line.  We could use any betting strategy we desired to allocate $40 per week.  The default strategy was to bet the biggest differences between the prediction and the line, allocating bets of $10, $8, $6... etc.  My own betting strategy was a bit more complex.  I allocated money according to the formula:

$$ =  80*ABS(Prediction-Line)/(100+5*ABS(Line)))

.The idea being to scale the bet to the relative magnitude of the difference between the prediction and the line.  A difference of 3 points is much more significant when the line is 3 than when the line is 27.

I predicted games from Oct 16 through the end of the bowl season.  My program doesn't account for neutral site games, so the bowl games were treated as home games for the higher-ranked team.  (This works well in practice on the basketball side for the NCAA tournament.)  I predicted a total of 224 games.  The results:

  MeasurePerformance
Correct game winner73%
Correct pick against the line56%
Betting result+$29

Overall, better results than I expected.  56% against the line is sufficient to be a winning bettor (if it can be maintained).

Thursday, January 5, 2012

A Call from Bill Hancock

(I promise to get back to the prediction stuff soon -- after a dalliance with NCAA football I've started to ramp back up for basketball.  In the meantime, this imagined scenario from last night, inspired by my earlier comment that the NCAA was only allowing ten players on defense to spice up the bowl season.)

Phone call at spacious Turner Mansion last night:

(Ring, Ring)

Me:  Hello?  Oh, hello Mr. Hancock.  How is your job as BCS Executive Director going?

Hancock: (mumble mumble mumble)

Me: Well, you're welcome.  I'm glad my suggestion to only play ten players on defense has worked out so well.

Hancock: (mumble mumble mumble)

Me: *Nine* on defense?  No, I'm not sure that's a good idea.  We've been counting on the fact that most sports writers can't count past ten.   So far they haven't noticed.  But you put nine players out there and someone is going to write about it.  And where does it all end?  Eight players?  Seven players?

Hancock: (mumble mumble mumble)

Me: No, sir, that was a joke.  I'm not recommending seven players on defense.  Listen, I don't think this is a good idea.  Baylor just obliterated the points scoring record for a bowl game.  This is Baylor, the doormat of the Big 12, a university whose only men's championship is in *tennis*.  And then you had Wisconsin -- Wisconsin of all teams! -- throwing the ball all over the field and scoring 38 points.  That's more than the Wisconsin basketball team scored last season.  I realize you want to turn it up to eleven for the Orange Bowl, but this is not a good idea.

Hancock: (mumble mumble mumble)

Me: You're worried about Clemson's defense?  With all due respect, sir, Clemson is an ACC team.  The last time the ACC won a meaningful bowl game it was actually played for a bowl.  If you gave the ACC space lasers they couldn't defend Fort Knox against a Boy Scout troop.

Hancock: (mumble mumble mumble)

Me: True, it is West Virginia.

Hancock: (mumble mumble mumble)

Me: No, sir, West Virginia is part of the United States.

Hancock: (mumble mumble mumble)

Me: No apology necessary.  It's a common misconception.

Hancock: (mumble mumble mumble)

Me: Well, you do what you have to do, sir.  Personally, I'm a traditionalist.  Just tell the officials the result and let them take care of it.  That's worked for Duke basketball for decades and no one's the wiser.  Do they have a "charging" call in football?  I can't remember.  But I'm sure you'll make a good decision.

Hancock: (mumble mumble mumble)

Me:  "Bet the over"?  Ha, ha, good one, sir.