R break

I’ve been playing around with 2010 Gameday data all night (courtesy of Niv, thanks as always!). Downloaded the R RMySQL plugin to help run the show, but unfortunately the only documentation I can find is this. I’m sure it’s got everything I need… but for some reason it’s all arranged in alphabetical order. So for someone just getting started, I have to guess about which command is relevant for where I am in the process (connecting, import data, run a query, save output) and go from there. Certainly doable, but not exactly the easiest.

For a bit of a break I figured I’d jump over here for a bit to talk about what I’m up to. First step in the process is this – calculating an AVG and SLG for each spot on the field by batted ball type. Using the XY data from Gameday and these park adjustments (I’m starting with the 2008 figures from here – even though I’m using 2008-2010 data – and will eventually tweak them as I see necessary as I become more familiar with the data) I’m coming up with a total list of all balls in hit into play and the rate in which the possible outcomes occur for that location on the field.

Once I get all that in, I’ll have to run a loop to help smooth out the data – for each spot/type, I’ll look at all the balls hit within an X foot radius (weighting balls on the periphery of that area less than ones at the center) and calculate a weighted average of all of the relevant stats.

Now there are a million and a half different reasons that this isn’t optimal (data quality, adjustment factors, player positioning, the way different parks play, etc) but it’s a reasonable start. This is the best data that I have available to me for now, and I think at the very least I can use it to create some fun maps in R (something I’ve been wanting to do for some time now).

Stars aligning

What a weekend.

Not that I wasn’t motivated to be working on this project before, but now we’ve kicked it up another notch. Niv was in town for the weekend and we had a whole lot of time to talk about where things are going and what it all could lead to. And I’m very much convinced it can lead to big, big things.

November 5. 32 days. Let’s go.

Denominators

So I’ve begun to think about some tables for TTL and as of right now I’m leaning toward showing everything per plate appearance (or at bat/ball in play when appropriate). Now for hitting stats this is how it’s done and it makes perfect sense. However for pitching stats, rate stats tend to be per inning or per 9 innings (ERA, WHIP, K/9, HR/9, etc.). Now it doesn’t make intuitive sense to talk about “earned runs per plate appearance,” but for everything else I don’t know why we still don’t use the same denominators as when looking from a hitter’s perspective.

For instance, this year Carlos Marmol is certainly having an outstanding season, striking batters out at nearly 16 per 9 innings (which would be a record). However, while much more than half of his outs are coming via the K, he has truck out 41.1% of the batters he has faced. This is slightly ahead of the 38.5% posted by Billy Wagner this season and trails the 44.8% posted by Eric Gagne in his 2003 season and the 42.5% posted by Brad Lidge in 2004. No doubt Marmol is having a very good season, but the choice of denominator here is what really counts. Excluding walks and especially hits from the equation doesn’t really make much sense in this case; why should the fact that a ground ball sneaks through the hole rather than become an out make a difference on how successful a pitcher is at striking guys out?

Therefore, what I’ve decided to do is display parallel stats for hitters and pitchers. These will typically be on a per plate appearance/at bat/ball in play basis, although I do want to show one of ERA/FIP/xFIP for pitchers and RC/27 for hitters (again to be parallel). Not only does this the process easier by keeping the same fields for both groups, to me it makes sense as the way we should be looking at stats. Hitters try to score runs, pitchers try to prevent runs; hitters try to get on base and pitchers try to make outs; hitters try to help their team win and pitchers do the same. Since it’s two sides of the same coin, why do we currently treat them differently in so many cases, even when looking at “advanced” metrics?

The Implications of Inning Limits

Recently I ran across a problem with my deployed version of ottoneu: there was no programmatic limit for games played or innings pitched for any given fantasy team.

Let me back up.

Fantasy baseball games, in general, have limits around the number of games a team can ‘play’ at any given position.  For example, if there are 162 games in a season, it doesn’t make much sense to allow an owner to manipulate his lineup enough to squeeze 170 games out of a given position.  This might not be possible for all owners, and it doesn’t fit in with the idea of mapping fantasy baseball to real baseball.  If the Yankees can’t go out on their off days and get extra games in with their backups, well, then, neither should your fantasy team that you’ve cleverly named after them.

Most games will run with limits along the lines of 162 games per lineup slot, which includes things like 162 games per OF spot (in our 5OF lineup, we have a 810 game limit at OF) as well as 162 games per special position (middle infielder, corner infielder, utility).  Innings pitched can be a little bit more varied, but we went with the tried and true multiply 162*9 and add a few extra to get to a nice round number, so our limit is 1500IP.

So back to where I started – ottoneu did not have programmatic enforcement in place for when teams went over these limits.  While this isn’t a gigantic problem with 12 owners, once you’re talking a game with leagues on the order of 100, then yes, we have a problem.  I decided to tackle the problem last week, and immediately an interesting question arises: when does the inning limit kick in?  Can you run right up to 1499.2 IP at the end of a day, and start 5 guys the next day and then the limit kicks in at the end?  Should there be a rule put in place that says when you are within some arbitrary distance of the 1500 IP limit at the end of a day, you can’t play any more pitchers?  Or the final option – add up stats until you hit 1500 IP, no matter if it is in the middle of a start or an appearance by a reliever or anything?

I kicked this question around with Geoff for a little bit, and we decided that first off, it made no sense to build any kind of lower buffer.  A 1500 IP limit doesn’t mean “1495-1500”.  We thought about calculating the inning count at the end of every day, but this solution again made a inning limit closer to “1500-1525” instead of the hard 1500IP cap that we wanted.  So that leaves the last option.

The idea of these limits, like I said, is not only to put everyone on equal footing, but also to line up the game against real baseball.  This last option, in which the live scoring script literally stops taking your statistics once you hit 1500IP, is the least connected to real baseball.  If I’m at 1497.0 IP, and Jon Lester going on the last day of the season (I know, it would never happen), there’s a very real possibility that only half of his start will count towards my fantasy statistics.  Cutting off starts in the middle divorces the idea that these player’s days line up perfectly with your team’s day.

We decided to go with this option, but where does that leave ottoneu?  The first line of ottoneu’s constitution is as follows:

The intention of this league is to mimic the job of an actual general manager as closely as possible.

Clearly managing who plays and who doesn’t on a day to day level isn’t on a GM’s plate, but if we our goal is to reflect reality, this solution is actively hurting us.  I don’t have any good answers here – one can go down the path of explaining the other ways ottoneu isn’t like real baseball, but I am not sure if that is a compelling defense of this solution.  Clearly the alternatives we discussed were not better than what we decided on, but maybe there was something else I didn’t consider?  I open it to the floor.

The best part of designing a game is that you get to run into interesting questions about the system you are building all the time.  Of course, that is also the worst part.

Sunday update

There are a whole lot of things that I like about my job. It’s interesting and rewarding work, and normally it’s not too hectic. However, the past 10 days or so have involved a lot of frantic coding so that we can publish one of our main products by October 1. Not that there’s a choice… it has to be out by October 1. And as Niv can attest, I’ve pretty much gone AWOL so that I can finish up everything for our website.

Working at this pace at work has really killed all desire to come home and write even more code, even if this code is much more fun. However, I did just now sit down and got True Talent Level looking a bit more presentable. Not that there’s any content there, but at least there’s a link over to everything that we’ve got going on over here (including Niv’s post, which was well worth the wait!).

I’ve been doing a few things behind the scenes, but really hope to step things up if possible this week. I’m seeing Niv the next two weekends in a row, and hopefully there will be a great deal of discussion about our respective projects and where we need to go next with them.

Frameworks

As the other half of this little venture, I have not been pulling my weight on this blog.  But no more!  It is my turn to chime in with a few lines of thought that might only be interesting to me.

My free time the last few days has been spent developing my side of the project, a new fantasy baseball game.  Developing is not the right word – more like refactoring for scale.  Right now the game is written to handle the one league and 12 teams that have been using it for the last 5 years.  However, if I want it to go anywhere, people should be able to sign up, create teams, join leagues, and so on and so forth.  So after multiple false starts, I’ve decided to take the working code I have now, refactor it for legibility and to fix the bugs that I have found, and push it out to the world next spring.

There turned out to be two clear options for me in considering scale for ottoneu.  One option is the one I took – take my manually written, inefficient, and generally goofy PHP and turn it into somewhat legible, slightly less inefficient, still remarkably goofy PHP that allows more than 12 people to play this fantasy game.  The other option would be to start over from scratch and develop a scalable, efficient piece of software against a proven MVC framework.  I tried the second path two or three times, and I’ve learned, basically, that I hate development frameworks.

I decided to work with Zend, a PHP framework with which I had heard good things.  I started from knowing nothing, and only towards the very end of my experience did I start feeling any bit of understanding towards the framework.  Basically, learning Zend was like learning a new language, but with this whole level of indirection on top of it – it looks like something I knew, but it wasn’t anything that I knew, and hiding everywhere in the framework was some call or some method that was the “Right” way to solve a problem.  Some people have this problem with base PHP – lots of silly built-in methods/functions, lots of ways of solving a problem, but the difference is that when using a framework, there really was the “Right” way and the dangerous way, whereas base PHP has multiple right ways, depending on what you are trying to do.

The second attempt at going down the Zend path had me hire a developer who had serious production experience with the framework and, I hoped, would be able to guide me and help me develop the new version of ottoneu.  However, the problems here were fairly straightforward – I still wasn’t learning anything about Zend, I barely had an idea of what was going on, and the developer was a freelancer, not invested or interested in being invested in the project.  So fine, this isn’t a beef against the framework, but… Goddamnit, I’m a reasonably smart person and a decent developer.  If your framework is too obtuse for me to pick up and build a reasonably complex project with, it isn’t doing its job.  All the “Hello Worlds” and simplistic authentication examples in the world won’t convince me otherwise.

So I decided, with a little help from this post from Joel Spolsky, to run with what I had.  Yes, it was ugly code.  Yes, I’m embarrassed to share it with anyone with anything more than self-taught PHP experience.  Yes, it had bugs galore, didn’t interact consistently with MySQL, and was way slower than it should be.  But look – it works.  The damn code works, and has worked for 5 years.  Best of all, I understand what I am working with – I wrote all this code, so I know what it is trying to do, how to fix various issues with it, etc.  And for just that reason, I know it will be faster for me to get to launch day, Spring 2011 than it would have been using Zend.

My conclusion is this – frameworks are good for someone starting out from scratch, but only if 1) the project is going to use a ton of the built-in help the framework gets you and 2) won’t need a lot of stuff that is outside the scope of the framework.  There are ways for me to eventually get my code to something much cleaner and more legible and even faster, but starting over from scratch was not one of those ways.

Next up, I’ll discuss a more interesting, more fantasy baseball-oriented topic: how do game and inning limits work?

Baby steps!

Remember this little guy? It only took two additional weeks but I can officially check #1 off the list! And by me checking it off, I mean Niv really checked it off by doing everything necessary to get it set up.

http://truetalentlevel.com

It’s obviously not much as of yet – it’s only been around for a few hours – but I’m going to start to play around with it a bit and work towards making some progress on goal #2. Obviously really digging into the data is the main priority before November, but I just want to do some of the web stuff up front so that I can add to it as I progress with the real work.

Off to play around with things a bit more!

Luck

luck (noun)
a: a force that brings good fortune or adversity
b: the events or circumstances that operate for or against an individual

Chad and Niv brought up some points in the comments to this post, and then I discussed things a bit further with them (in person in the case of Chad!). The biggest problem with that post is that i just basically categorized events as being luckly/unlucky without any real definition of the term. Well, I guess I was using the above definition, but there is way too much room to interpret how that may apply to baseball. In addition, there is a big distinction to be made between luck on an individual play and luck over the course of an entire game – I was confusing the two in a bit in that post, and will try to be a bit more distinct here.

Let us take a step back first and think about a game which is much more simple than baseball: darts. Let’s say you hit a bullseye; if you were to recreate the same exact physiological motion from the same exact location (location meaning physical structure and placement within that structure) and environment (same noise level/people moving around you) with the same exact grip that you used to hit that bullseye, you would with 100% certainty hit it again. You only depend on your own talents for an individual throw, so there is no luck involved whatsoever. Because the game itself is practically unchanging (you might have to aim for a 17 instead of the bullseye, but you are still the same distance away and using the same darts) and is turn-based (as opposed to interactive between the various players), you aren’t really competing against someone else as you play but rather you are competing against yourself relative to someone else competing against themselves (assuming you are not playing with teams). Your own performance can be neither lucky or unlucky; rather, you as an individual reap what you sow. However, because you yourself have no control over the performance of your opponent, the final outcome of the game may be lucky or unlucky based on how they perform relative to what is expected of them: if they hit numbers more quickly than they are expected to then you are unlucky, and if they hit numbers less quickly than they are expected to then you are lucky.

A game that adds an additional layer of complexity to darts is pool: it is turn-based, played in a climate-controlled environment, and uses a consistent set of equipment. However, unlike in darts the placement of the balls creates an infinite set of possible situations in which one can face. A player can repeat the same motion given the same situation and get the same result as in darts – therefore there is still no luck involved on an individual shot – but unlike darts they must be prepared to deal with any number of situations. Since these situations can range in difficulty from simple to impossible, it is possible for one player to face a much easier set of shots than the other. However, since leaving your opponent difficult shots is a skill in itself, this must be taken into account when trying to determine the role of luck. Therefore, one is lucky over an entire game of pool if they face easier shots than expected given opponent quality and/or have more opportunities at shots given opponent quality (due to unexpected misses by the opposition).

Golf seems to be a mixture of these two games to me – while the required shots change significantly over the course of a hole, each player is responsible for where their ball lies and plays no role in shots of the of their opponents. However, weather is brought into play for golf – an unexpected gust of wind blowing a shot off the green, for instance – and this means there is the potential for a slight bit luck on an individual shot (I would say this is slightly more common than someone dropping a glass while you are about to take your shot in pool, but overall it is pretty similar).

However, over the course of an entire tournament golf is a bit different than the other two games due to the fact that: 1) there are many more holes of golf in a tournament, reducing the volatility of the performance of each individual competitor; 2) there are many more competitors playing, reducing the volatility of the performance of all competitors in aggregate; and 3) the weather can change, potentially creating different conditions for the various competitors. Points 1 and 2 lead to the conclusion that, for the most part, you can have a pretty good idea about how the tournament scores will be distributed before it even starts. However, these may be affected by point 3. Also, while the overall distribution of scores are what matter for a tournament, when it comes to winning it is those scores on the end of the distribution that matter, and these will still be a bit volatile. Nevertheless, one can be considered to be lucky over an entire golf tournament if their competitors have performed worse than expected given the weather which they have faced and/or if the competitor has played in more favorable weather conditions than the rest of the competitors overall.

Finally, baseball. Let’s skip over the whole pitch selection part of the equation (which deserves a whole different post in itself) and just deal with balls in play. If you throw the dart/hit the pool ball/hit the golf ball where you want to throw/hit/hit it, then on an individual basis there is very little luck involved (except for dropped glasses/wind gusts). In baseball, however, there is no such guarantee. If you hit the ball exactly where you want to hit it in play, there is some non-zero probability it will turn into an out. And due to the nature of the game, is is much more difficult to hit a baseball exactly where you want it than to throw a dart/hit a pool ball/hit a golf ball exactly where you want it. That means that, on an individual play in baseball, there is some luck involved. A batter is lucky on a single play if the value of the outcome of the play exceeds the expected value of that ball in play. As samples increase in size this luck should even out somewhat – over a career there should be very little luck, but over the course of a game it certainly still plays a role in the outcome.

Note: I extracted some of this post in its original form for this so just imagine this as all being a prequel to that post.

RE: Chad

I have a really big post coming, but I’m driving to cleveland tonight and there’s no chance I’ll be able to finish it. So here is a little digression from the middle of it all that pretty much stands on its own. I hope to post the rest sometime this weekend.

Chad wondered: can we look at luck on individual plays or does it only make sense in aggregate? We discussed this over brunch for a while (our fiancé’s were thrilled), and I think the answer is yes, you can look at individual plays. In my original post, I didn’t specify what the odds were that the shortstop got to the ball, but in my head I was imagining a play that would be a hit maybe 90%-95% of the time. Now is that 5%-10% unlucky or just unlikely but inevitable? How about this play? That’s a home run 99.999% of the time, and I think we can all agree the guy who hit that was unlucky.

After a lot of thought, I realized that any cutoff is an arbitrary cutoff and in reality we should only be talking about degrees of luck rather than bucketing everything into categories. From a batter’s perspective, every hit is lucky and every out is unlucky. It’s a bit like win probability added insofar as every hit increases the chances of a win and every (nonproductive) out decreases the chances of a win.

A ball in play which is a hit 50% of the time that is turned into an out is unlucky, and that same ball when it is a hit is equally lucky. A ball which is a hit 99% of the time that actually results in a hit is lucky, but just a little tiny bit lucky. A ball which is a hit 99% of the time but is turned into an out is about as unlucky as you could be. getting 6 hits on 10 balls in play with an expected hit total of 3.6 is lucky, but not as lucky as getting 7 or 8 or 9 or 10 hits on those same balls; 5 hits in that situation is still somewhat lucky, but relatively less lucky than what actually happened. And if you’ve got a 30% chance of a ball in play turning into a hit and it does, that’s equivalently lucky to getting two hits on balls each with a 54.8% chance each of turning into hits or getting three hits on balls each with a 66.9% chance each of turning into hits (using the binomial distribution: 30% = 54.8% * 54.8% = 66.9% * 66.9% * 66.9%).