Tangotiger Blog

“We organize baseball data to be able to answer baseball questions.”

In that case, you should report out the observed release points, not the x0 and y0. Don’t mix and match TM observed and PFX-style derived data if you want to use that stuff to “answer baseball questions.”

Those of us with direct access to the data won’t be troubled by this, but the general public isn’t being given the best service in this model. I hope you guys reconsider and provide all the relevant data, labeled accurately, to the interested public.

Harry:

I’m not sure which issue you are referring to.  So far, the only decisions made are:
- report the release speed out of hand
- decide later on how to report on anything else related to speed

Are you questioning either of the above?

If not, which pieces of data specifically are you referring to?

but you still report “release” as x0 and z0 where y0=50. This is a mismatch. Trackman provides:

x0 z0 & speed at y=50, pfx style

and

the observed extension (y) release height (z) and side (x) along with the out of hand speed.

Those data points are groups, they go together. Right now your public data is showing x0 and z0 with observed speed. You should just include the observed release points (and for people who don’t’ like math, give them speed at 50, too, pfx style)

Voila, legacy problem solved. And an interesting change for people to compare the two data groups.

Harry, let’s take it one item at a time, so we can have a clean thread.

And just so we’re clear, and for the benefit of everyone else, let’s take this game:

http://gd2.mlb.com/components/game/mlb/year_2017/month_04/day_04/gid_2017_04_04_anamlb_oakmlb_1/plays.xml

The data shows this:
x0=”-1.57201170439372”
y0=“50”
z0=“5.98118856133437”

In the file, that makes sense.

You are pointing out that that in some places, we are showing yOutOfHand, AT THE SAME TIME as showing x0 and z0.  If that’s the case, then I agree with you, that is a problem.  Can you point out where you are seeing this?

My suggestion to you, or to anyone, that when you find a bug or inconsistency or mismatch to just let me know, here or email or Twitter, and I’ll get the data engineers to take care of the glitch.

After your response, let’s talk about your next item.

Is there a reason speed at 50 feet is no longer being released? Seems like that’s pretty important to have in order to contextual use the new values. Right now we’re just working with averages.

No, you’re showing ax ay az vx0 vy0 vz0 x0 y0 z0 and a speed value, in the old/legacy field, that’s speed out of hand. You shouldn’t overload a data field like that. Add a new one, sure, but also add a new one for the release points.

So, to summarize, you have two types of release/speed data.

Currently you are showing both, using the old labels, while one value (just the speed) is from the new format.

My suggestion is you keep the old data the same, and add new fields for out of hand speed and release location.

We have a good technical reason not to create a new field for out-of-hand.

Basically, your point is that as long as we show all the pfx-style 9P values, we should also show the “speed” value.

However, the speed value IS there… that’s vy0.  It’s in feet per second.
vx0=“7.58164156353356”
vy0=”-138.144049724025”
vz0=”-7.17835256741307”

That vy0 is 138.144*.681818 = 94.2 mph at y=50.

The value here:
start_speed=“95.1”

That’s out-of-hand.

Therefore, I think the legacy issue is that people have been using the “start_speed” field when they could just as well have used the vy0 field.

Therefore, all the data IS there, in a consistent fashion. Isn’t it?

I will stay out of the debate between Harry and Tom.  Instead I’d like to make a physics-y comment on the change in speed values shown in the tables.  Namely, the 2nd table shows that the %change for a given extension is almost completely independent of release speed, varying by at most 0.2% over more than 20 mph of release speed.  The actual speed shifts varies by ~0.3 mph over that range of release speeds (first table).  This is exactly as I would expect based on how air drag affects the speed, where the amount of speed lost when traversing a given distance is a fraction of the initial speed.

Just so you understand the technical reason: we have hardware and software setup in all 30 ballparks, as well as our own stuff, and the vendors.  “start_speed” is THE value that everyone uses.  To make things transparent for everyone, they don’t need to change anything. They just keep going after the same endpoint they’ve always gone after.

The people who do need to change are those that want things old-style.  And you can do that right now, by accessing one of the 9P values.

Assuming this resolves the speed issue, is there another item to address?

Alan: good stuff.  And let’s not forget, the y=50 is based on a model.  Therefore, if the expectation is that the percentage value should actually be much closer to 99.1%, rather than varying between 99.0 and 99.2 (but correlated to the speed, giving constant extension), that may simply be a limitation of the model.

***

And there’s no debate!  I’m just trying to answer questions and solve any issues.

Tango/#7, I’m pretty sure that’s not the formula for PITCHf/x’s start_speed.

Best-
Dan

Dan: I meant that (starting in 2017) that it was pfx-STYLE, generated by Trackman. Does that make more sense?

Also, regardless of what happens here, re-purposing the start_speed parameter is going to be quite challenging for people going forward. I can speculate that it was done to avoid updating dozens of legacy systems and code, but it’s going to be a bear for someone at some point in the future, especially because the previous value (y50) is quite different from the current value (yR, which is quite close to ~y55).

We are essentially unaffected by the change, but many will not be (including, I assume, mlb.com).

Tango/#12, I believe start_speed at y50 was sqrt(vx0^2 + vy0^2 + vz0^2), not simply vy0 in mph.

Dan: thanks for the correction regarding the v at y=50. You are correct about that. It’s been a very long time since I used the v values, thanks for the reminder.  Much appreciated.

And your speculation is correct, as you may have missed Tango/9. The important constraint was the real-time endpoints. The fallout of that has to be handled.  Whatever we did, someone wasn’t going to be happy.  We chose the path that we did because it made the most sense. 

I updated the main thread to include the above info.  You can see it by searching for “UPDATE”.

Thanks again, I appreciate all the helpful comments and will address all concerns that come up.

My working motto comes straight from Chris Dial: we’re all on the same team.

Tango/#15: If I go to MLB.com and look up a player’s velocity over the 2012-2017 seasons, do I get:
a) the y50 start speed for each year 2012-2017, or
b) the y50 start speed parameters for years 2012-2016 and the yRelease start speed for year 2017?

I ask because a lot of people are going to do this, especially this time of year. If the answer above is (b), everyone is going to report that velocities are increasing, but they aren’t - they’re just being measured from a different place.

Dan: those are excellent points. You sound alot like me, when I would target Keith and Clay for their inconsistent models!  Keep it up.

On a more serious note: I’m not directly involved with the site, so I can’t answer it perfectly, but I’m 99% sure it’s b). 

MLB.com would report anything in that “start speed” field, however we populate it.  As it stands, we had one provider that was supplying whatever data they did through to 2016.  And now we are using the same field, populating it with out-of-hand. 

In terms of the “adjustment”, this has been discussed internally before the season, and it’s going to be handled in some manner.

Tango/#18: I am not trying to needle you, I am just having a difficult time reconciling what you’re telling me.

As an analogy, this would be like if you decided to recode batting average to include walks as singles, inflating everyone’s batting average, but also provided the raw table of BB, 1B, 2B, etc., and made the point that the change wasn’t so big because people could simply recalculate old batting average if they wanted to.

As it stands, most people who go look at that data (i.e., not through the XML files, but through MLB.com) will as of today be given the wrong answer about the thing they are trying to investigate (velocity has not gone up, it’s just being measured from a different point). This is quite subtle. 

The remainder (those who can look at XML files) will need to carefully follow this blog in order to do future research on pitcher velocity, because the field has been overwritten with a new definition ten years in.

Right, two issues going forward: One, how do researchers make sure they are comparing apples to apples when using multi-year data.

Two, what’s the best form of data to use for baseball related questions.

This is a great characterization of that:

The guy who released it with longer extension (i.e., closer to the plate), released it, out of hand, at 95.7.  The guy who released it with shorter extension, released it, out of hand, at 96.0.  Are those two equivalent, from the perspective of the batter?

I don’t know (yet).  If they are not equivalent, then there’s no real purpose to reporting the y=50 value.  We don’t calculate data for the purpose of calculating data.  We organize baseball data to be able to answer baseball questions.

and I am very interested in the answer. I would think that for any reasonable and similar distance the pitch is released from home plate, the most important thing in terms of the batter’s perception of the pitch (which is mostly what we’re interested in) is the speed when it crosses the plate (or the speed at y=X).

Of course, if I understand Alan correctly, a 95 mph pitch at y=50 will lose MORE speed by the time it gets to home plate then a 90 mph pitch.

Alan, the loss in speed due to drag is proportional to initial speed AND the percentage changes as well? Or it’s just proportional?

E.G, a 100 mph and a 90 mph might lose 1% over 55 feet, so that they arrive at 99 and 89.1, respectively?

Or the 100 mph pitch might lose 1.1% and the 90 mph pitch might lose 1%?

MGL/#20: Perhaps this will make the issue clear.

When you and Tango described wOBA in The Book, you did not call it Batting Average. It is a better tool for estimating offensive output than Batting Average, and so you thought it was an improvement. But you didn’t call it ‘Batting Average’, because that would be confusing to everyone who knew what Batting Average was, and you certainly didn’t put tables of batting average from years 1980-1996 and then suddenly start calculating wOBA in those same tables starting in 1997 going forward.

start_speed has always been start_speed at y50. start_speed at release may be a better variable for answering baseball questions. But it is not start_speed at y50. Overwriting the old variable is simply confusing, regardless of whether the new variable is better for analysis.

If I have a new calculation for OBP or wOBA, I’d keep the same name.  I’d just make sure to fix it for all data that I have to do it.  If I happen to not have HBP, I’d still call it OBP, and have an asterisk saying “no HBP collected”.

Therefore, in order to report things honestly, we’d simply say “speed through 2016 reported at 50 feet from back tip of home plate; speed since 2017 reported out of hand”.  So, that should happen at some point soon. That’s clear and honest.

Does MLB have an additional obligation to do the conversion to make the equivalencies?  I don’t know.

But start with this constraint, which cannot be changed: start speed is the variable being used for real-time and it’s going to be reported out of hand.

That’s the starting point.  If you can provide any kind of solution or recommendation that adheres to that constraint, I’m all ears.

Tango/#22: Regardless of what you choose to do, and it seems like you have already made up your mind about this, can you report start_speed to the same significant digits in the Gameday Components files and on Baseball Savant? Currently, Gameday Components are reporting to the tenths place, and Baseball Savant to the hundredths place.

Dan: I haven’t made up my mind about anything, so please don’t characterize it as such.  I have a constraint, and it’s straight forward: start speed MUST be out of hand.  It’s that simple.

I am not imposing that rule.  It’s a rule that’s in place for me (and everyone at BAM) to work with.

***

I wasn’t aware of any sig digits issue.  I’ll look into it.

And I VERY MUCH appreciate the comments.  Anything that moves the ball forward for me, or for the reader, are great comments.

OK. I apologize: it was my understanding that you were the one tasked with making these sorts of decisions. If this is an organizational ultimatum that you’re simply living with the same way we are, sorry for misappropriating it.

Tango/#22

You didn’t notify the community that this change in the definition of pitch velocity happened before opening day. There was no asterisk and no explanation until this morning. Whole articles were written about velocity spikes that were incorrect—because there was no explanation or disclosure of the change you made.

From the perspective of a journalist who hopes to write articles based on the statistics you provide, that becomes a very risky proposition when those statistics are subject to revision at any moment, with no explanation or notification until after the fact. I’m very, very grateful you provide this information to the community, and it powers a lot of the analysis we do. But if you are going to provide this data, you have a responsibility to keep us updated when said data changes.

Does anyone here know much about velocity reporting before the pitch f/x era?

Would speed measured by a radar gun likely be near the pitcher’s release?  Near home plate?  Halfway in between?  Or completely variable depending on where the operator points his gun?

Tango - If I am interpreting what you said above about all the data in MLB Components coming from Statcast (Trackman)that means that other parameters that analysts have been tracking will also change.  Spin will be measured directly instead of computed from acceleration as was done by Pitch Fx.  Also, pitch xy positions as the ball crosses the front of home plate will also be measured directly rather than extrapolated from data measured 10 or more feet away as was done by Pitch Fx.  The only thing we don’t know is how accurate and consistent the Statcast (Trackman) measurements of these data are.  Seems like that would be important to find out at some point.

Rally - The explanation that we were given about why Pitch Fx chose 50 feet for computing the Start_Speed was that that distance came closest to giving pitch speeds that matched the hand held radar guns that were being used previously.

Dan: thanks, much appreciate it. 

It’s easier for Sean and David and Harry to do whatever they want, because they are, essentially, benevolent dictators (as the E Street Band lovingly characterizes Bruce).  In our case, it’s more like the EU. For example, Savant is a silo next to MLB.com.

***

Rob: I don’t disagree with any of your post, other than this:

“...are subject to revision at any moment, with no explanation or notification until after the fact”

This was purely a transition from one provider to another, and that’s an off-season change. There are alot of different parts of the organization involved in terms of disseminating information to different endpoints. 

Tango/#30: I don’t know much about the organizational structure at Fangraphs or B-Ref [although I know the people at both groups], but I can assure you that Harry does not rule by fiat at BP or at BrooksBaseball.net. We’ve had ongoing collaborations for the better part of the same 10 years PITCHf/x has been around, and I can’t remember him making such a capricious decision.

Peter/28: Right. And that pitch data will all be available to the public. I read every research piece from everyone. So I look forward to whatever it is that you guys discover.

I’m not sure you had a point other than to highlight areas for research?

... and I can’t remember him making such a capricious decision.

It wasn’t capricious. 

It’s a reasonable thing to say:
“let’s report on the thing we actually observe”,

Just as it’s reasonable to say:
“let’s take the thing we observe, and then infer what it likely was at some other point, and report that, because that’s what we’ve been doing for 10 years”

Can we agree that BOTH statements are reasonable?  As long as both are reasonable, then EITHER choice is fine. 

So, even though it wasn’t my decision, I’m on board with it. I’m 60/40 with it really.

Tango/30
I’m not sure what this means…
“There are alot of different parts of the organization involved in terms of disseminating information to different endpoints. “

There wasn’t any *public* disclosure, to my knowledge (and if I’m incorrect, please let me know), of this very important measurement change until today (or maybe yesterday, when someone spoke with Dave Cameron for his article). Respectfully, I don’t know why you couldn’t have published this blog post a week ago and have avoided the whole problem.

Also, while I understand that this was an off-season change, I’ve seen evidence of changes to Statcast during the season over the past couple of years. So, this kind of hidden data provider change has been happening both in-season and during the off-season, and I don’t know why it can’t be disclosed. If you think it’s an improvement, why not tell us so?

Sure. Were there no existing standard, either of those would be fine.

Similarly, were there no existing standard, we could report Batting Average to include walks as singles, because they are quite similar batting outcomes and only differ by .15 LWTS or so, which is a small number on the order of a tiny fraction.

What would be capricious would be to change Batting Average - a metric that exists - so that, this year, but not for any other year, we reported BB as 1B in the BA formula but didn’t tell anyone about the change ahead of time.

I actually like the fact that you’re reporting speed out of hand, because it enables us to do some neat things, which are likely to be posted on BP.com sooner rather than later. And, because it’s much easier to explain to people (“this is the velocity when the guy releases the ball”), as opposed to something more complicated (“this is the velocity at a whole number value chosen to match the approximate location at which radar guns used to approximately report speed when that was a thing”).

However, I *dislike* the fact that you’re reporting this new thing in the same place as the old thing without documenting or announcing the change, and the fact that you’re reporting this new thing as if it were comparable to the old thing. This is, essentially, the very definition of capriciousness.

I think we are in broad agreement about the fact it is generally good to be reporting speed out of hand. What we’re in disagreement about is how it’s being done.

I think alot of your post can be rewritten in a more Q&A format, rather than presuming things.  For example, this…

Respectfully, I don’t know why you couldn’t have published this blog post a week ago and have avoided the whole problem.

... which reads to me like an opinion or a conclusion, can be rewritten as:

Respectfully, can you tell me the earliest you could have possibly written this blog post?

And my answer is: late last week is when it first came to my attention that we’d be reporting the out-of-hand as the primary value. I’ve never been involved in that whole side of the operation, the real-time reporting.  I get my data post-game. From my perspective, nothing has changed in terms of the data I get.

I compiled the data Friday, and I wanted to meet with the engineers and data distributors this week, so I could get all my facts down. Dave’s excellent post accelerated my plans.  I published this blog post with whatever I could gather.  Indeed, I went too fast, because I had forgotten the point that Dan brought up.  So, I will be updating that chart as soon as I finish typing this response.

Also, while I understand that this was an off-season change, I’ve seen evidence of changes to Statcast during the season over the past couple of years. So, this kind of hidden data provider change has been happening both in-season and during the off-season, and I don’t know why it can’t be disclosed.

First, I’d give 2015 a pass.  That was the first year, and glitches are bound to happen, when you are testing in a production environment.

We have software and hardware updates all the time.  If you are suggesting that we should disclose those updates to the public, I don’t know how we’d necessarily do that.

We COULD have the engineer write a blog post saying “this is what we’ve been working on and doing”. And maybe we all could appreciate how much they have to do to keep the operation running.  It’s a massive engineering undertaking to make the system as ubiquitous as it is.(*)

All the clubs get those alerts every time we do an update.  Everything we know, they know.  They are our customers (owners in reality, clients in practice).

As an example,  say I change how I calculate catch probability because I get more data, and what I had originally estimated as 25% has been changed to 27%.  And I do this not just for one value, but for ALL values.  38% becomes 37%, 87% becomes 88%, and so on.  Is your suggestion that I disclose this every time I re-run my model with more data?

***

(*) I was a jerk once to Justin Kubatko at Hockey-Reference.  He did a massive amount of work to get HR the site it is today.  I was a huge HockeyDB.com fan, but what Justin did at HR turned me on to it.  But, I was getting picky about something (I think it was the points % because of the overtime loss system).  Basically, he had to play the good guy because in the position he’s in, he has to be the good guy.  He probably could have said something more forceful to me, but he was restrained. 

I realized how I acted pretty poorly, and apologized profusely to him in private.  He accepted it, and there’s been zero animosity.  Indeed, quite the opposite, highly respectful both ways.

Right around that time, I also said something impulsive (to no one in particular), and Chris Dial said: we’re all on the same team.

It was then that I realized that all the little bickerings that I’ve done to that point were probably causing more harm than good.  I was definitely well-intentioned then, as I am now, and always will be.  But the message has to be respectful.  And I have to take a look at the bigger picture.

There are reasons that things happen that may not be to my immediate liking, but I have to presume decisions are being made out of reason not malice.

I wrote (the top half of) Tango/36 in response to Rob/34.

The Pozterisk part is just stream of consciousness.

Dan/35: I think my response to Rob/34 applies to your post.  If it doesn’t suffice, please feel free to expand on your point.

Re: Tango/36

“We have software and hardware updates all the time.  If you are suggesting that we should disclose those updates to the public, I don’t know how we’d necessarily do that.”

I do think that following the precedent set by the mobile application platforms would make sense. When an app updates but doesn’t fundamentally change things (i.e., raw data outputs are unchanged, only calibrations are made, etc.) a simple change log is listed.

However if something changes and an app now needs to access your phone’s contacts or something like that, there’s a big notification that says “hey, this is new you should take a look”. I’m not sure how frequent major updates are, but it might suffice to release a blog post weekly or whatever frequency makes sense for minor changes, and then have a larger post about bigger ones (like this) to make sure people are aware.

Since that format is one we’re all already familiar with, I think people would find that agreeable (at least in terms of transparency and awareness of changes—not necessarily agreeing with the changes being made, of course).

Hmmm…. I can check how we handle our mobile apps for baseball and hockey, and we can potentially make that the standard for Statcast.

Thanks for the great idea!

I chatted with the developer of the mobile apps.  We’ve never done it but he’s open to the idea.  Thanks for the suggestion, we’ll talk about it when things slow down a bit…

Anyone, feel free to propose any idea.  Love to hear them.

Image files have been updated to handle the issue Dan brought up.  Thanks much, and a bit more inline with Alan’s expectation.

You may need to refresh your browser.  If that doesn’t work, do this:
- right click image
- open in new tab
- go to the new tab
- refresh that tab