Thursday, April 26, 2007

Backtracking in All Its Guises

I promised a piece on backtracking in scoring (this is one of the rare times that you, Mr. Reader, probably wish that somebody wouldn’t have kept a promise; just remember there is always a “back” button on your browser). And so here it is.

The heart of the matter is that backtracking, in some form, is bound to pop up in any scoring system. The only question is in what form and to what extent.

In the traditional approach to scoring, there are scoreboxes for each player’s plate appearances. In the box, you mark what he does in his PA, in addition to what he does as a baserunner should he happen to reach base. Taking an example from the Texas/Los Angeles game I scored last night(4/2), Kenny Lofton led off the game with a walk. While Frank Catalanotto was batting, he stole second. Catalanotto walked, then Lofton advanced to third on Michael Young’s double play ball, which retired Catalanotto. In order to record that event, you had to mark the double play in Young’s box, and the out in Catalanotto’s box, and the advancement to third in Lofton’s box. This necessity to mark in multiple boxes for one play is what backtracking generally refers to.

The specific case in the Rangers game was not too bad because those guys were in consecutive lineup slots. It is possible that you would have to mark in as many as four scoreboxes for one play and go back as far as five slots back in the batting order.

So the traditional method has what I call “recording” backtracking; in order to properly record the events, you must backtrack. It also necessarily has some “readback” backtracking, if you want to replay the game in sequential order. You can look in Young’s box and see that he hit into a double play, but you have to go back to Lofton’s box to see that he was able to advance to third on the play.

However, it avoids another pitfall, which is what you could call “reconstructing”, relative to seeing the action a particular player was involved in. I can look at Lofton’s scoreboxes for the game and see all of the action that he was involved in; his walk, his steal, his advancement to third; I don’t need to go hunting through other boxes in order to see Lofton’s fate once he reached base. This is not the case for some other scoring systems.

The Project Scoresheet system was originally invented by Craig Wright for his own uses, but was eventually adopted as the standard method for Project Scoresheet. PS differs from traditional scoring methods in that it breaks each scorebox into three lines. The top line is used to record events that occur during the plate appearance, like a steal or a wild pitch. The middle line is used to record the result of the plate appearance, such as a single or a flyout. The bottom line is used to record the advancement of the baserunners.

The stated benefit of this system is that it does not require backtracking to previous boxes, at all. It doesn’t even require backtracking to previous lines within the particular scorebox. However, this property results in some very severe, and in my opinion intolerable, reconstruction problems.

Before I air my grievances though, I should point out that Project Scoresheet’s goal was to collect data for all major league games, and to disseminate it efficiently. The straight sequential, no backtracking approach would work very well for inputting games into a computer. So judged by the standard of doing what Project Scoresheet needed to do, the system is fine. Judging it as a method of keeping score for the heck of it is where it fails.

If the Lofton walks to leadoff the game, and you enter this into the computer, the computer remembers that. And so when Michael Young hits into the double play, and you mark “2-3” (the PS code for the runner at second advancing to third) on the bottom line of the scorebox, the computer understands that this runner at second was Lofton. But when you are a human, reading the scorecard back, you don’t implicitly know that, unless you remembered it, in which case you don’t really need to consult the scorecard at all. So instead you have to go looking back in the previous boxes to find out who that guy was. And this is not necessarily made easy for you.

For the same reason, it is difficult to look at the scorecard after the game and see how many runs a given player has scored; you have to run through all of the action to see this. It is very hard to glance down at your scorecard during the game and figure out where the baserunners currently are, which to me is one of the basic reasons for keeping score--keeping tabs on the game, even if you don’t have access to the scoreboard of the “FoxBox” or what have you. For this very reason, after a play happens, and you have to record the baserunner advancement as a result of that play, it is difficult to figure out where they started from so that you can write in the codes like “1-3” or “2-H” or what have you.

So while PS eliminates, almost perfectly, recording backtracking, it introduces a large amount of readback backtracking with respect to the identity of the baserunners, and it takes away a lot of the ability to quickly describe the situation at the moment that it occurs. I can easily accept that it is the fastest way to score, or the easiest to input into a computer, but as an everyday-use scoring method, it gets an F from me.

The other alternative method for scorekeeping is Alex Reisner’s Situational system. His method involves marking the baserunners’ location at the outset of every plate appearance. Any advancement during the PA (stuff that would go on the first line in PS) is marked on the diamond in the scorebox. There is a line on the bottom of the scorebox for recording the outcome of the PA, similar to the middle line in the PS system. The advancements made by the baserunner as a result of the PA are not marked, except to circle or underline the number of the batter if he scores. You can see where they ended up by looking at the next scorebox, which will mark their new position.

This, similar to PS, eliminates recording backtracking, with the exception of how putting dots in the center of the diamond of runners who scored or similarly indicating the out number in the box of the player who was retired. It does have some of the reconstruction problems of PS, as you can’t just look at Lofton’s boxes to see what he did; however, Reisner makes it a lot easier for you, because you can look for Lofton’s number in the other boxes, unlike PS where you would have to pick through the boxes, making sure to remember what base he is on at any given moment.

One annoyance of the system for me is that you have to record the uniform number; I always use lineup slot, but that doesn’t set apart substitutes from starters easily. I also don’t like having to mark down the location of the baserunners every single PA. For me, the traditional method is still better then situational, but I can see why some are fans of the situational method. I don’t understand the appeal of the Project Scoresheet system unless you have a microprocessor for a brain.

No comments:

Post a Comment

Comments are moderated, so there will be a lag between your post and it actually appearing. I reserve the right to reject any comment for any reason.