DEV Community: Ian Greengross

You Need Data to Analyze Data

Ian Greengross — Fri, 22 Nov 2019 05:49:59 +0000

So, my project for the ChiPy Mentorship program is: take the universe of NFL Running Backs and try to predict their contract value for their 2nd NFL contract. The reason for only predicting the 2nd NFL contract is that their first NFL contract is based on a mostly pre-determined system, where their 2nd contract is based off their performance in the NFL.

Unfortunately, this means that our number of samples to analyze in the post-2011 Collective Bargaining Agreement (CBA) era is approximately 100. (Side note - in 2011 a new 10 years CBA was negotiated which somewhat altered the system, so only contracts negotiated since then would be apples to apples).

As you will see below, when you only have 100 samples, using just about any method to analyze the data in order to predict a contract from a validation sample becomes almost a fool's errand. As of this post, and the methods will be more fully discussed below, we (my mentor and I) have tried: multiple linear regression, principle component analysis, decisions trees and K nearest neighbor. In addition, just on my end, I have also tried banging my head against the wall. More than once.

Ok, before I walk you through the methods we tried, you should know a little more about the data itself. For those 100 samples contracts, we have approximately 50 features of data for each one. Some are the 'normal' statistics people would associate with NFL running backs - total rushing yards for a given season, total receiving yards for a given season, total rushing touchdowns for a given season, etc. Some are 'advanced' statistics for running backs - yards per route run, yards after contact, tackles avoided and several others. Across each contract there about 50 statistical categories.

Multiple Linear Regression

So, before I would just willy nilly send all 50 features through linear regression, my mentor suggested just plotting a simple relationship plot with r^2 on the plot for each feature to see if that feature had any realistic chance of being relevant to the outcome. So, I did:

cols_we_want is just a list of the column names that I wanted to check their relevance.

That code gave me 50 .png files that look like this:

And with just a little bit of code, 50 features became about 8 - all of which I could have guessed before the computer did its math because they are the features which are used in the 'real world' in which these contracts are negotiated.

However, just to make sure that those features were indeed the most relevant, a little RFE (Recursive Feature Elimination - which basically ranks the features in terms of their relevance for predicting the outcome) was necessary:

Which then gave me a listing of how relevant each feature was to the outcome - several columns rated as a '1', then '2' and so on - with a 1 being most relevant.

Brimming with confidence that our most relevant features would absolutely predict outcomes that were right on the money, I wrote the code to run linear regression with the level '1' features, then the level '1' and '2' features and so on:

Unfortunately, this is when the fears of my mentor were first realized: Not having enough samples means not getting accurate predictions.

However, fear not dear reader, the world of data analysis has many other methods to try. And next on the list was PCA (Principal Component Analysis) - which to use a technical term - mushes the features together into as many or as little a number you want:

Unfortunately, once again not having enough samples means not getting accurate predictions.

But, where one door closes, another opens. Welcome to decision trees:

However, I'm sure by now you have guessed the theme of this post - not having enough samples means not getting accurate predictions.

Time to call in K nearest neighbor off the bench....which, funny enough should approximate what happens in the 'real world' anyway. When I negotiate a contract for a player I represent, I look at the other players at his position whom I believe to be the most statistically similar and use their contracts as a baseline for the contract I want for my player.

Tune in at the final presentations on December 12 to see how it all turns out. (If you miss it, don't worry - I'll make a final post as well).

Data is now a little less hard

Ian Greengross — Fri, 18 Oct 2019 03:53:01 +0000

Previously I wrote about how Data is hard. Well, thanks to my mentor, Data is now a little less hard.

In these last few weeks, I have become an 'expert' at culling out data by using whole columns, rather than using the good old 'for' loop. For example, in order to get the data of how successful an NFL Running Back is on first down, I used the following code:

all_rbs = data.loc[(data['play_type']=='run') & (data['down'] == 1) & (data['ydstogo'] == 10)].groupby(by='rusher_player_name')[['epa', 'success','yards_gained']].mean()

Which gave me some output that looked like this:
Joe.Runningback 0.042594 0.57182 4.63

Except that it output one row for each running back in the dataset of all NFL plays from an entire NFL season.

However, given my newfound merge skills, I was then able to take that list of data and merge it into my main data table which has a record for each running back so that I now had 3 new columns for how a running back performed on 1st and 10: Expected Points Added (per play), Success rate, and average yards per attempt.

I was able to repeat this process many times over so that my final data table had 72 points of data (or features) per running back.

And, now, data was a little less hard. That is, until we moved forward to the first step in turning that data into a model that can actually predict something.

Once again, my mentor took my hand and taught me the basics so that I could start using the data.

Rather than just run all of the features through regression (or any other) analysis, he suggested that I first take each feature and run a regression plot against our target to see if the feature has any meaning in the first place. Since I had no idea what to do, he sent me some links and talked me through the general idea. This led to me writing this code, all by myself:

from scipy import stats
import pandas as pd
import seaborn as sns
import matplotlib.pyplot as plt

all_rb = pd.read_excel('rb_all_data_a.xlsx')
all_rb.set_index('Index', inplace=True)
cols_we_want = []

for a in range(18,90):
col_name = all_rb.columns[a]
cols_we_want.append(col_name)

for col in cols_we_want:
def r2(x, y):
return stats.pearsonr(x, y)[0] ** 2

sns.jointplot(x=col, y='Average_Salary', kind="reg", stat_func=r2, data=all_rb)
plt.savefig(f'{col}.png')
plt.close()

And, bingo, bango, bongo, in 20 lines of code, I had 72 regression plots with r^2 listed on each plot so that I could start to weed out those features which would likely prove insignificant.

Now that the features have been cut down, I'm excited to learn the next step and steps so that we can build a prediction model.

Principal Component Analysis, here we come....

To be continued.....

Data is hard.

Ian Greengross — Tue, 17 Sep 2019 19:12:00 +0000

I understand data. I spent my late teens and early 20's programming in the languages associated with some of the first DOS based relational databases - Paradox and DBase IV.

So I understand data structure and what data looks like.

But, when you're trying to merge together data from 4 or 5 different sources, where the only key across all of them is a person's name and that person's name can be used differently in each set (Ian Greengross, I. Greengross, IG 01, etc) - then you need to find a way to get those keys unified.

And while my project only involves 32 individuals, I didn't want to do it the "cheap way" and just add column and put in my own key manually.

So - I actually had to think about the data and how to automate giving each individual one unifying key so that when the data is merged, the right data gets assigned to the right individual.

And, guess what? I did it. It wasn't eloquent, but as Zax says, the first rule is - if it works, then that's good enough (or he tells me something to that effect.)

Then after I finally had a way to make sure that each person's data would be properly merged into their "record", I then had to deal with the fact that I would be assigning the same info types/column names into each individual's record, but for different years AND those years varied from individual to individual.

I again wrote another ineloquent script, which again worked. But I would have to rewrite dozens of lines for each script to cover the varying years and rewrite each script every time I moved on to different data tables.

This is where I had left off when I had my first meeting with my mentor, Matt.

In all of about 30 minutes, Matt showed me a much more efficient way to join the data and to do it in a way where I really didn't have to re-write anything to cover the shift in year and only had to rewrite some column labels when I moved on to the next data set I wanted to merge.

In those 30 minutes, Matt saved me from a few hours of rewriting and also helped me to see and think of the data and its structure in a new light.

Which makes data just a little less hard.

For now.