March 26, 2006

preliminary results

As mentioned previously, I wrote a lineup simulator in C to run through all 9! permutations. I tested it against the 2005 Astros. The full results are here (6.8 MB gzipped text file), but here are the top 10 and bottom 10 lineups.

The classic lineup:

This lineup clocks in about 1 run per game lower than was actually scored last year. Part of this probably is due to not accounting for steals, defensive errors, or sacrifices.

Top 10:

Bottom 10:

For reference, here's the output from the Baseball Musings lineup analysis tool.

Surprisingly, my simulator strongly suggests loading all of your best hitters up front. The leadoff position suggests putting someone with a good OBA (as you would expect) and then straight away putting your best two sluggers in the next slots. There also seems to be some support for the second leadoff batter theory here as well, with Taveras in the 9 hole. At best, the non-traditional lineup nets me about 12 runs on the season over the classic lineup. That's maybe one win. The differential between the best and worst possible lineups is pretty significant, around 10%.

One thing to consider; NL numbers might not be the best numbers to test this on because there are a lot of double switches in the back third of many games when relievers are brought in which changes lineups considerably. My next run, I think I'm going to take aggregated numbers for AL lineups.

Feedback:

TrackBack URL for this entry:
http://www.falsecognate.org/cgi-bin/mt-tb.cgi/508

Comments:

  1. I love this kinda shit. Anyway, there has to be some serious problem with your simulation, because as you noted your run scoring is way too low. There's no way omitting steals, errors, and sacrifices can cut scoring almost 25%. I'm not really sure what the problem is though.

    I've read some of Cyril Morong's shit before...I don't think much of him as a sabermetrician. Or as a writer. However, The Book, discussed in that Hardball Times article, is quality shit. I've been reading things by Tangotiger for a few years and he is absolutely brilliant. The Book's chapter on lineup construction does confirm the validity of the "2nd leadoff hitter" strategy. Tony LaRussa batted his pitcher 8th a little bit a few years ago

    It would be interesting to see what your model projects should be the best lineup for Houston in 2006. For instance, Ausmus is not gonna put up a .351 OBP again, so he shouldn't really be leading off. Of course, this depends on what projections you use. If you are interested you could try these: http://www.baseballthinkfactory.org/files/oracle/discussion/2006_zips_projections_houston_astros/

  2. Actually, I think that steals, errors, and sacrifices probably will bring my run total pretty close to what the 2005 Astros scored. Errors account for about 40 runs (25% of the difference). There were 42 sac fly (which by definition each score at least one run) equalling another 25% of the difference. 82 sac bunts is hard to put a definitive run scored number to, but if you're conservative and say that's 20 runs over the course of the season, that's another 10% or so. And with 71 net stolen bases, we get even closer.

    I think the real thing is that if you start factoring in steals (and runner speed) that could significantly change the order. Ausmus isn't really that fast - maybe Taveras' speed on the bases plus steals is worth 30 points of OBP in the leadoff spot, who knows? I'm going to try to rewrite the program to include steals; that will require me to keep track of which player is on which base (right now it just checks to see which bases are occupied, and not who is on them). In turn, that ought to provide a stepping stone for writing a routine for player-dependent baserunning.

    Overall, the results make sense. Each successive position in the lineup sees about 4-5% fewer at bats, so obviously you should put your best hitters up front. However, if your worst batter (generally the pitcher in the NL) is more than 5% worse in offensive performance than the next batter (a pretty good likelihood) you probably shouldn't put them in the 9-hole, i.e., next to your best batters. Once I get the program rewritten, I'll probably run it against both the 2005 Astros, and then test it against the ZIPS projections or Baseball Prospectus' PECOTA projections (although I don't really want to shell out $40 for a BP subscription). I'm also trying to parallelize the code - it takes something like 55 hours to run the program on one computer, so adding multiple computers to the computation should dramatically accelerate it.

  3. Hmm. How did you calculate errors accounting for 40 runs? That might be right, but I wonder how you figured it. I don't know how many errors were made against Houston last season, but the average NL team made 101.5 errors. The average run-value of an error is about 0.5 runs. If you knock that down a bit for throwing errors on stolen base attempts and plays with multiple throwing errors, it could be about 40-50 runs.

    You say you didn't include SF, but those aren't so much a skill as simply a batter's propensity to hit flyballs while a runner happens to be on third. Rather than being part of each batter's inputted statistical profile, they should just naturally happen once in a while when runners reach third with less than two outs. This makes me wonder -- what rules did you set for runner advancement? Do the runners ever move up on outs? Do they ever go first-to-third on singles? If every play is base-for-base, that could account for a lot of the shortfall, though I couldn't really guess how much.

    As for the SB, I don't think the key is the 71 net steals. It's the SB%, which is 72.3. Depending on when those steals and caught stealings actually took place, that probably netted Houston a few runs, but not that many.

    The sac bunts would also depend on the actual context, but on average a sac bunt has a slightly negative value. I would call it a wash. I don't think you can presume they were worth 20 runs.

Post a comment

You must sign in using either TypeKey or OpenID to comment on this entry.

OpenID/LiveJournal:

TypeKey:

Meta-info

Categorical

Temporal