THE BOOK--Playing The Percentages In Baseball

I’m just fine-tuning my simple Markov program, which I will release shortly.  The major disadvantage in the program is that it doesn’t handle outs on base.  This is a problem of course, but for such a simple program, it’s still pretty powerful.  This problem is neatly balanced out by turning all reached base on error as outs.  For example, by doing so for 1974-1990 data, I get 4.27 runs per game, instead of the actual 4.29 runs per game.

Anyway, one of the very cool things is that we’ll be able to generate an RE chart for any run environment you can think of, even for a million runs per game!

The other cool thing, which is an offshoot of the RE, is that we can get Linear Weights.  For example, in the 1974-1990 run environment, I get these LWTS values, for walks, singles, doubles, triples, HR:
.37, .49, .77, 1.07, 1.48

The walk value is much higher than I would want, and the single is a little bit higher than I want, as is the HR.  The reason for the walk is that walks are distributed evenly in my program, when in reality it is not.  This causes a .02 run effect.  As for the single and walks, because there are no outs on base (principally DPs), this gives the illusion of the run value of being on 1B is higher than it should be.  Not sure yet why the HR is where it is, but chances are it has to do with the outs on base issue.

Now, let’s bump up our run environment so that our team has an OBP of .500.  The runs per game is now at 14.4.  What is our new LWTS? 

.63, .76, 1.02, 1.24, 1.52

We can see here how the HR run value barely moves up, while the other events all move up by around .25 runs.

What if we shoot up the run environment so that the OBP is .750?  Now, we have 65 runs per game.  The new LWTS values are:

.88, .96, 1.09, 1.18, 1.31

We see here that the run values of most events start to converge towards 1.00, as expected (according to BaseRuns).

Finally, let’s bump up the OBP to .900.  That’s 226 runs per game!  The run values are:

.96, .99, 1.04, 1.07, 1.12

We can see now that all the events are rapidly converging towards a run value of 1.00 for each one.

This Markov calculator should become the basis in which to evaluate all run estimators (with some adjustments for the issues discussed).

The Markov can be used to try to improve the BsR B factor, right. Cool.

As far as not using regressions, etc., to come up with run values---I don’t necessarily agree. Let’s say you use the BsR addendum formula with the correct weights for all the events from that period. Then, you eliminate from the formula all but the main 6 outcomes. In order to still get the correct run estimate, the “plus 1” weight for a 1b will now be (say) .485 instead of the correct .463, and so on. So, the “correct” values only work if you have all the outcomes, which is not the situation most of the time.

I’ve had this discussion with David at Fanhome in the past.  My opinion is that you should separate what you know from what you estimate.  If for example you eliminate all but the 6 main outcomes, and if the run value of the single has to be shifted to compensate for the missing variables, I would present it as .463 runs for the single, and +.022 proxy-runs for the single.

This way, it becomes clear with what we know (the .463) from what we dont (the .022), instead of combining them into .485, and then having to explain when it changes to .481, or .477 as more information is added.

It also saves us from the ridiculousness of what XR and Jarvis does, when the run value of the double is .15 or .22 runs higher than a single, a choice made solely to comfort the regression (which itself has a high enough uncertainty that the .30 would have been supported).

No prob with the splitting into actual and proxy components (other than it’s a bit cumbersome). And as far as the silly extra .15 for a 2b, how much of that is a fundamental problem with regression, and how much is just an ‘implementation’ problem? Schell got .32/.52/.80/1.11/1.49, I think. Is he doing a better job of controlling for the interactions of the outcome types?

It all depends on what is in your sample. 

For example, if I use the 1,818 teams from 1919 to 2005, my regression says:
.37, .57, .82, 1.51, 1.41

That’s right, the run value of the triple is HIGHER than the HR.  I did not include SB in the regression.  The standard error of the triple is .05 runs, which means we are 95% sure that it should be between 1.41 and 1.61.

The correlation coefficient was a super strong 0.97.  Nonetheless, to trumpet the triples 1.51 run value would be insane.  To instead say that the triple should be 1.1 runs, and that the “speed-proxy” of the triple is .41 runs is more acceptable.

Regressions help in guiding you, or leaning you somewhere.  But, to rely on it as the end-product, or to any great extent, without adhering to some basic principles, is foolish.

What if we instead try to use some common sense.  A triple can be considered a double + speed.  So, let’s lump the triples and doubles together.  As well, we’re pretty sure that the run value of a triple is .3 runs higher than a double.  So, you start with the number of runs a team scored, and remove .3 runs for every triple.  And then, lump the triples into the doubles.  Here’s our new regression:

.37, .58, .87, 1.17, 1.35

This certainly makes alot more sense than the earlier regression.  The r is still 0.97.

What if we make the triple .25 runs higher than a double?  Now we get:

.37, .59, .88, 1.13, 1.34

The r is still 0.97.

In any case, we have the PBP data, and we have a good run modeler.  We don’t need to do these regressions.

Tango

Great stuff as always. I have a quick question for you about how you change the run expectancy environment in your Markov.

Given the outcomes (ie, value of a base /out situation, or an event) is driven by the change in the run environment I am assuming that you have to adjust the probabilities in your transition matrix. For example, under a run environment of 5 r/g you may have a the 0 on 0 out state as transitioning to a 0 on 1 out state 65% of the time, but in a 10 r/g state it might be 50% of the time, with the remainder somehow distributed across the other possible transitions.

I guess the questions is how do you know these are the right transitions? Do you just make the state changes, run the Markov and retrospectively work out the run environment? Or is there a more intelligent way to adjust the transition matrix?

That’s the great thing about the Markov calculator: I don’t have to do any of that!  All I care about is: the frequency of events (singles, hr, walks, etc), and the frequency of taking the extra base (single, man on 1b, 0 outs, or out, man on 3b, 1 out, etc).  That’s it.  You plug those in, and the perfect mathematical calculation produces your total runs scored.  It’s as simple as it sounds (if recursion makes any sense to you).

So, what would really change as you change the frequency of singles, etc, up, is the chance of taking the extra base.  After all, as the team OBP starts going up, you have a much smaller reason to try to take the extra base, to the point that when the OBP approaches 1, your chance of taking the extra base will plummet.  (i.e., you only take the extra base when you have an almost 100% chance of making it.)

My calculator will give you complete flexibility to put in whatever numbers you want.

Cool - so basically what heppens is that the frequency of each event forces you into a specific base out state - so the more singles you have the greater the odds are that you transition into a state with a man on 1st + ...

I like it. Look forward to being able to play around with it when you release your program. I actually built a Markov in Access but it is slower than a 3-legged dog so I never use it. Also I just use a transition matrix generated by PBP data and haven’t taken the additional step that you have which forces the event into the matrix.

"It all depends on what is in your sample.”

I don’t agree, from what I’ve seen. Schell’s sample was all teams 1947 thru 2003. That is not much different from the 1955-1998 (or whatever) used by other researchers who got those low 2b values. He mentions that each event has been adjusted for its own park effect, instead of an overall run adjustment or no adjustment at all.

I still am not sure whether the problem is with regression, per se, or with the implementation.

David

Does the regression have the same sample size—my reading of Tango’s post is that he regressed season data. It could well be that Schell regressed all games played, which should give you a much lower standard error around each of the weights. Don’t know - just a thought ...

John, he used all teams 1947-2003.

A regression on the 1,310 teams in the Schell sample gives me an r of .973, with the following coefficients:
.50, .70, 1.22, 1.50, .36, .13, -.102, -.11

The last 3 are SB, regular out, strikeout

If we remove SB, K from the variables, we get and r of .972 with:
.52, .74, 1.19, 1.46, .36, -.104

They are “close”, but you do end up with numbers that are a bit off.  For example, the run value of the double is +.22 to the single.  The triple is +.45 to the double.

Like I said, we have the Ruane data for 1960-2004.  That should be the basis.  Here is the team-aggregate regression against those years:

teams: 1,132
r: .976

.51, .68, 1.16, 1.49, .33, -.101, -.102, .20, -.24

The last 4 terms are: out, K, SB, CS

Removing the last three as variables, and we have:

.52, .73, 1.22, 1.45, .35, -.103

Compare this to the actual (Ruane) data of 1960-2004:
.46, .75, 1.03, 1.40, .30

My take on using regression is that over enough samples then you should get a similar weight value to a Markov process. However, over the course of a single season there aren’t enough games to get a low enough standard error on some of the less frequent weights eg, triples, so the value look somewhat off.

However, if you want a run expectancy matrix post 1960, say. Then if you have the result of every game in a regression I would imagine you’d get a similar result to doing a Markov - though I haven’t done the analysis myself

The 95% range for the events, even with the sample size over 1000 team-seasons, is around .10 runs. 

If you were to run a regression on team-games instead, just one season will get you over 4,000 samples.  That chops your error range down to .05 runs, 95% of the time.  If you use team-innings instead, you’ve got 40,000 samples, and your error range goes down to the .01, .02 range.

So, if somene wants to run a regression, do it at the inning-level, for even just one season.  You will likely find that if you do it, one season at a time, that the coefficients will come out very close.

Still, with all that said, I’d like to know why Schell’s result differs from Tango’s. To pin it down, Schell used 1947-2003 (1310 teams), and the categories 1b,2b,3b,HR,(BB+HBP), and (AB-H). His results were .52/.80/1.11/1.52/.32/-.111

If Tango’s (or anyone else’s) regression on the exact same data gives a different result, then why? As I said, Schell mentioned something about park adjusting each outcome individually. My impression is that he did that before the regression. Is that the key to getting reasonable relationships among the resultant values?

There’s no reason to park adjust, unless you think a, say, double at Fenway is worth more or less than a double at Wrigley, etc.

That’s certainly a possibility.

Running a regression on the Redsox from 1946-2005 (60 teams), I get an r of .97, with the following coefficients:
.47, .78, 1.47, 1.43, .46

(The triple value is the highest.)

However, the standard error is enormous.  The 95% range for the double is +/- .28.

Most people who run regressions do so at the team-level seasonal aggregates.  This has the double impact of introducing a bias (say baserunning), and severely lowering your sample size (changing 162 samples into 1).  While the uncertainty level of this big 1 is smaller than the 162, why bother if you have such an enormous number of samples to draw from?

So, that’s what I did.  From 2000-2006, I have 34,004 team games.  The average runs per 27 outs is 4.84 (or .537 per inning).  Here’s the results of the regression for a few basic hitting stats:

r=.87

0.52 notHR
0.29 2B
0.56 3B
1.41 HR
-.15 BB
-.10 all outs (batting, baserunning, etc)

notHR is H+BB-HR-IBB
2B is the extra run value, over and above the single
3B is the extra run value, over and aove the single
BB is the run value relative to the single

The largest standard error was for the 3B, obviously, with a 95% range of .52 to .60.

So, compare that to the results from the main blog entry at the top of this thread:
Another way to look at the data is with respect to the run value of the single:
RperI __2b-1b__3b-1b__1b-bb
0.525 __ 0.30 __ 0.61 __ 0.16
0.550 __ 0.29 __ 0.57 __ 0.15

A delta Run Expectancy (delta RE) process tells us that the double generates .29 or .30 runs more than a single.  That’s the same result as our regression at the game level.  The triple, according to the delta RE process says .57 to .61, which is in-line with the regression at the game level.  The walk should be .15 to .16 runs less than a single, based on the delta RE, or the game-level regression. The HR is always around 1.40 runs.

The biggest difference is the run value of the single (.52 using regression and .47 using delta RE).  The reason is that the “outs” figure I used in the regression is all outs, batting, and baserunning.  So, if you try for the extra base on a single and are safe, that’s a plus for the single, but if you are out, that’s not counting against the single.  Same deal for SB, CS, GIDP, which are not explicity represented here, and are therefore includes implicitly in 1B, BB, and outs.

While the relative value of the walk is 0.15 runs less than a single any way you cut it, by starting the run value of the single at 0.52 runs (according to the regression) gives us a run value of the walk at 0.37 runs.  That is, the cost of the walk (CS, GIDP) is not included in the walk, since we’ve separated the out portion of the walk away (into the “outs” variable).

What’s also interesting is that if you run the Perfect Run Modeler, you will get results for the single/walk as too high as well (to a similar degree).  And, that is because the modeler does away with baserunning outs altogether.

"As you can see, as the run environment increases, the run value of all the events, save for one, pretty much increases.”

There’s an interesting pattern to the increase in each event value as overall environment increases.  Comparing lowest to highest environment:
HR 0
3B +6%
2B +10%
1B +12%
BB +21%
Clearly, the on-base component becomes increasingly valuable as advancement component becomes less valuable.  It’s not just that the HR is uniquely stable.

It would be a bit better if you look at it from a differential standpoint.  The walk, single, double, triple each advance, pretty much, in lock-step, as I demonstrated at the end of the main blog entry.

I always wanted to do a study based on game-level rather than seasonal-level stats.  And, apparently, I did so in post 20.

Did anybody else remember I did that?  Depressingly for me, is that while I don’t remember half the studies I’ve done, I remember all of Bill James’ studies from 20-25 years ago.