pitchfx-site
pitchfx-site copied to clipboard
kruser
Pitch Count Heatmap
I wanted to see where a pitcher was throwing most of their fastballs this year compared to last and discovered that we don't have a simple pitch count heatmap.
I think we should!
All of the heatmaps can be filtered by 1..* pitch types using the table right above it.
For example, here are swing rates on fastballs for a pitcher.
The denominator for all the pitch zones would have to be all pitches, regardless of which / how many pitch types are filtered. Problem I see with this is that rare pitches are going to show all blue no matter what. We may have to create a scatter charts for 'Pitch Selection' charts. All of our heatmaps right now are rates.
@albertlyu, we have a denominator in the calculation in the Zone.js only, but in reality it just needs to return a number and highcharts will plot everything relative to each other. So I think the Zone.js function would just need to return pitches.length.
Right, so I suppose what I meant to say was that the denominator for each pitch zone would be all pitches in that pitch zone, which would be the same across all combination of pitch types for that particular zone. But an additional concern is if a pitcher throws a lot of fastballs up in the zone, all other pitch types will be skewed because there will be a large pitches.length up in the zone. It would not show a good estimate of where a pitcher tends to throw his curve ball -- showing pitch selection would have to deviate from our current set of heatmaps, in my opinion.
So for example, a pitcher could throw the same exact number of curve balls in the same exact locations in year 2012 vs year 2013, but if has a very different distribution of fastballs between both years, the curve ball % heatmap would look completely different even if the curve ball selection behavior was the same between the years.
Yes, I agree. I think the chart would get useful though if the user checks pitch types in the table above.
But if the use case of a pitch selection chart is to determine where a pitcher's fastball location has changed from one year to the next, then we would have to use a scatter chart or a heatmap like here http://www.fangraphs.com/blogs/riveras-cutters-working-the-count/ which calculates the z-axis (heat) through kernel density estimation. Unless I may be misunderstanding what you're looking for here?
OHhhhhh pitches.length = total number of fastballs if only fastballs are checked... not total number of pitches inside that zone regardless of pitch type. My apologies.
^ yes.
Looking for this... http://www.brooksbaseball.net/profile.php?player=502043&time=month&minmax=ci&var=count&s_type=2&startDate=03/30/2007&endDate=04/17/2014&gFilt=&pFilt=FA|SI|FC
The Zones.js are compiled based on pitch types selected (or all if none are selected). So there is no need to bother the Zone.js function creator with those details.
Alright, in that case, would you want to add another collapsible panel to the accordion on the left? We may want to come up with additional pitch count heatmaps if so.
Forgive my ignorance, but could this also lead into a study of pitch selection based on count? For instance, for a selected pitcher, given a certain count, what pitch would he be most likely to throw?
Yep, probably not presented in a heat map, but yes we should show that data soon.
I have a task open on the atbat-mongodb project to add balls and strikes to the pitch data. Right now our db isn't ready. I'll try to get that ready within two weeks. On Apr 17, 2014 11:01 PM, "patrickjmcd" [email protected] wrote:
Forgive my ignorance, but could this also lead into a study of pitch selection based on count? For instance, for a selected pitcher, given a certain count, what pitch would he be most likely to throw?
Reply to this email directly or view it on GitHubhttps://github.com/kruser/pitchfx-site/issues/68#issuecomment-40785225 .
Yup, pitch selection based on count would be a great addition to the heatmaps, e.g. first pitch, behind in the count, ahead in the count, and two strike scenarios. We'd be filtering for pitch type, then by count (and potentially base-out situation, etc.), not the other way around (which is what the filters currently allow). The issue in atbat-mongodb is here: https://github.com/kruser/atbat-mongodb/issues/5
@patrickjmcd, I'm looking at a lot of other modeling changes in that atbat-mongodb project that will require a from-scratch ETL, so I don't have anything at the top of mind to do there. For this project, let's just keep encapsulating our functionality properly, like we do with the Pitch.js methods.
I think this issue can be completed without any ETL changes though if anybody wants it.