from Amazon
Wednesday, October 18, 2006
Updating BaseRuns
We know we have a problem with the triple. Here is an adjustment that “works” from OBP of .100 to .999. From an OBP of .000 to .100 (i.e., less than 0.10 runs per game) the run value of the triples is bounded at no lower than .500, when it should drop below that level, eventually to zero. But, I think we can live with that.
Anyway, the change is not elegant, but it works. This is what you have to do:
1 - In the “B” equation, set the coefficient of the triple to match whatever you have for the HR (that is, instead of using 3.1, use 1.7). The “A” equation continues to have the triple.
2 - Calculate BsR as you normally would. You will have severely undervalued the triple.
3 - Calculate your score Rate as you normally would, meaning B/(B+C), and create a fudge factor for the triples as:
TriplesFudge=(1-scoreRate)/2
4 - To your original BsR total, add:
number of triples x TriplesFudge=
In my base example that I’ve been using, the scoreRate is 0.321. So, I add an extra .340 runs for each triple to my BaseRuns total.
The result is that my triples value will now be almost always half-way between the run value of the double and the run value of the HR, and I’ve never been able to make the run value of the triple exceed that of the HR in all my testing from OBP .001 to .999.
It’s not elegant, but it “works”.
The interesting thing about the triple is that you *can* score from 3B on an out. The problem with the standard scoreRate formula, B/(B+C), is that this is not a possibility, in BaseRuns. And in fact, in my perfect Markov model, the run value of the triple is a very robust 0.25 runs, when then Runs Per Game is an extremely low 0.10. And undoubtedly, at this low a run environment, a runner will try to score from 3B on anything close. If I bump up the chance of scoring from 3B just a bit on an out, I get the run value of the triple to above 0.500 runs. Therefore, I feel justified saying that the run value of the triple would probably floor at around 0.500 runs for all run environments.
I’m glad that you were able to find a correction; I wouldn’t worry about it not being elegant because it probably only needs to be pulled out in extreme situations anyway.
Of course, as I have mentioned before, I have never really been too concerned about the triple problem because there are other things that are more bothersome and cause more error, like the LOB problem. And then there are other things that cause problems in low-scoring extremes, like negative BsR due to negative B coefficients. I think that the thing to remember is that B/(B+C) is just an estimator, and it works pretty well, but it will be impossible to solve all of those problems while conforming to that construct. Of course, whether there is a better construct out there, and finding that construct, is a lot easier to speculate about then to do.