Methods section — Cluster analysis of ballparks: An exercise in failure and futility

When people talk about how different ballparks play, there are certain terms and concepts that are regularly and almost exclusively used. Coors Field is a Hitter’s Park. So is Chase Field. Petco is a Pitcher’s Park. On rare occasion, it might get a little more specific — i.e., AT&T has Triples Alley — but in general the conversation doesn’t get much deeper. Just because it’s not done, however, doesn’t necessarily mean it can’t be done. Is it possible to use data, specifically park factors, to group major league ballparks into more well-defined groups than just good-for-hitters and good-for-pitchers?

I set out to accomplish this through the statistical concept of clustering. Now, this seems like an ideal spot to mention that I am NOT a statistician, and so there’s a decent chance that some or all of what follows is a complete misuse of good techniques. That said, I think everything was used correctly, and hopefully my editors here will kill this piece off entirely if it makes no sense.

Additionally, I’ll mention that everything done herein was done either in MySQL (for data storage/retrieval), Excel (for easily assembling the needed data), or R (for actual data analysis). MySQL and R are both free programs, and the Excel stuff would have been just as easy with any of its free competitors.

Still reading? Good - here we go.

The first step in the process was deciding on a set of park factors to thoroughly characterize the different aspects of how MLB parks play. I wanted to capture run environment, power hitting, the likelihood of batted ball types (grounder, popup, etc), true outcomes, and in-play hitting. This was complicated in part by the fact that publicly-available information on batted ball types is… not ideal. Although Retrosheet has complete batted ball-type records for all seasons since 2003, it relies on stringers to classify them, leading to inconsistencies in what counts as a pop-up, line drive, fly ball, etc. They’re perfectly reliable for on-ground versus in-air, though, so that’s the split I used.

I ended up picking nine park factors, split by handedness (so, eighteen factors really): LinearWeightsRuns/G, LWTSRuns/G on ground balls, LWTSRuns/G on balls-in-air, Ground Balls/Ball-in-Air ratio, Home Runs per PA, Strikeouts per PA, Walks per PA, ISO, and BABIP. In each case, I calculated the park factors myself, using the procedure I’ve written about before at this very site and taking a five-year park average. The linear weights I used were also calculated myself empirically and individually for each season (see the wiki at Tango's site for details). Based on advice from BtBS’s own Neil Weinberg, I wanted to include a baserunning measure, but couldn’t find one that seemed both worthwhile and calculable from the data I have access to. Since these measures include batted ball types, I only looked at data from the last twelve seasons.

In order to group ballparks with respect to these eighteen park factors, I (or rather, the clustering algorithms) needed to know the distance between each park’s factors. This isn’t as straightforward as it may seem. If each factor, or variable, were independent of all the others, it would be an easy calculation that you’ve seen a million times before — he square root of the squared differences between the points in each dimension. In two dimensions it’d be sqrt((a2-a1)^2+(b2-b1)^2), which is easily enough expanded to the eighteen-dimensional space of my data. However, I can say confidently that these park factors are not independent of each other, but instead exhibit some covariance; that is, some of them vary in related ways. HRs per PA and ISO, for example, will tend to vary in the same direction. Because of this, I used an alternative distance metric called the Mahalanobis distance (calculated via the ecodist package in R). The Mahalanobis distance takes into account and corrects for this covariance in a way I’m not remotely qualified to describe, and normalized based on each variable’s standard deviation across the data set.

So, armed with a data set of park factors and a matrix of Mahalanobis distances between them, the only thing left was to decide on a clustering algorithm, run it, and show all my cool results. Unfortunately, as you may have guessed from the subtitle of this article, it wasn’t quite that easy.

I narrowed the wide variety of clustering choices available in R to the two types that were easiest for me (and probably for you) to understand: hierarchical clustering and partition-based clustering. Both have strengths and weaknesses, are easy enough to explain in plain English, and completely failed at finding reliable structures in the data here. Hierarchical clustering, specifically the bottom-up kind, starts with all data points being in their own group of one. It then merges the two closest and recalculates the distance between all groups (by one of several available methods). It continues until all points are put together into one giant group, and presents you with the distance between each group that was merged throughout the process. This is commonly presented as a dendrogram.

I also used one of the tools available in R to attempt to predict the ideal number of groups. The NbClust packages provides a function that runs any of up to 30 tests that purport (and I use that word because I have no idea how they all work) to determine the correct cluster number, and then reports the average from all the tests you choose to run. I ran the full complement of tests, using k-means as the clustering algorithm of choice since k-medoids wasn’t available, on my data, and got 27 results. The large plurality (10/27) told me to use two clusters, and second-place was a tie at 6/27 metrics each between three and thirty clusters. So, in other words, over 80% of the tests I ran told me my best options were effectively meaningless groupings. No other number was in the results more than once; the other five results were 5, 6, 16, 23, and 29.