DEV Community: loganwohlers

Scraping the NBA p1- Players/Teams

loganwohlers — Fri, 12 Jul 2019 18:05:47 +0000

As a side project - I've been building out an NBA API using free statistics from basketballreference.com. Ultimately my goal is to provide a simple API for anyone who wants to use basketball stats so no one else has to jump through all the hoops that I have- why the NBA doesn't provide free JSON data is beyond me- but that's where this project comes in. The best current option is balldontlie.io which is nice but doesn't provide all the statistics the API I'm envisioning should have. So to remedy this I've been working on scraping this data in mass and saving it to my own personal database that will be hosted somewhere with documented endpoints. The project is decently close to release- and I've got the scraping process down which I figured I would expand on here. I started this project in Rails using the Nokogiri gem but have since switched to using Node and Cheerio/Puppeteer to do the scraping work-- the process is basically the same but since I've been more into JS lately I'll go from that perspective. So without further ado here's part one of this series-- Players and Teams.

Let's start with teams since I will go much further in detail on them on a later post. For now- the 30 teams in the NBA (RIP SONICS) are hardcoded in a static JSON file- with each having an object that contains the team's name, city, conference, and tri-code (ie LAL for Los Angeles Lakers, ATL for Atlanta Hawks, and so on). There is a corresponding table in the database with this information- so whenever team data needs to be seeded in the process is as simple as running through this file and creating rows for every team. In my current build teams also have seasonal data with their average stats as well as their opponents- which can be found at this URL (https://www.basketball-reference.com/leagues/NBA_2019.html). This will be expanded on in a later post but for now a simple team table is more than enough to start with our players.

Now on to some actual scraping for player data. The current database is set up such that a player is their own entity- that is they don't BELONG to a team, rather a player plays player_seasons that belong to a team and a season. For every season basketball reference provides a table containing every player who finished the season on an NBA roster along with their season averages (ie https://www.basketball-reference.com/leagues/NBA_2019_per_game.html). A quick inspection on the page reveals the table has an id of #per_game_stats. So using any scraping method we first load in this url and then get straight to this table.

All of the actual player info is contained in the body- so we get to the body and search for all table rows and start to iterate through them for our data with something like a for loop. For every row in the body we have to loop through all the td cells and get their data. I just made an empty array and then for every row's td mapped out stat names and their values into an object that was pushed in. The names of the stats are actually provided inside the td's as an attribute called data-stat- which lets you just forego using the table header column names and get all relevant data straight from the body. Here's a snippet of what that simple code looked like.

 let result=[]
 const tableBody = $('#per_game_stats').children('tbody')
    tableBody.find('tr').each((index, ele) => {
        let row = {}
        $(ele).find('td').each((index, ele) => {
            let statName = $(ele).data().stat
            let statVal = $(ele).text()
            row[statName] = statVal
        })
        result.push(row)
    })
    return result

With all this set up- to actually seed to database I just had to find or create a new row for the player's name (first value in the row), find the pre-seeded team's id using their tri-code, and create a new player season row with references to the said player and team. This process is actually very fast given there are only ~600-800 players contained in this table every season.

Next week I'll dive a bit deeper into the harder part-- taking a season and seeding a boxscore for every game (1230 in a season). So stay tuned.

Thanks for reading and let me know any questions/comments!

Logan

Intro to Hash Tables (JS Objects Under the Hood)

loganwohlers — Mon, 13 May 2019 01:08:43 +0000

In the world of data structures and algorithms Hash Tables are extremely prevalent. As someone who primarily is working in JavaScript- I haven't really had to deal with them-- because like so many other things- Javascript abstracts them away (spoiler: they are Objects). However in the interest of learning DSA material I spent some time this weekend looking into them and hoped to share what I've learned to help demystify this common data structure-- and to give a better look into how an HOW an Object stores it's data and then goes and retrieves a value when you give it a key.

To understand the inner-workings of a Hash Table let's run through an imaginary problem checking whether or not an array includes a value.

We have an array of [1, 3, 4]. How can we check whether this array includes the number 5? The easiest solution is to just iterate thru the array-- checking each value and seeing whether or not it equals 5- and ultimately returning false since the above array doesn't have a 5. This is fine but this solution is done in O(n) time- that is, the time it takes to solve this problem depends on the size of the array. If we had an array of length 10k and we wanted to check if it included a specific value it would be very time consuming- in the worst case we would have to check ALL 10k indices before we could answer that question. So with this in mind how can we solve this problem in O(1) or constant time. How can we instantly go and get the answer to whether or not our array contains a specific value- regardless of it's length?

Let's take another approach--we could use an array of booleans to represent whether or not the value of that index is contained within our original set of values -(ie a true at index 1 means that the number 1 is contained)- this would look something like:

Values:     1     3  4
 Index:  0  1  2  3  4
   Arr:[ F, T, F, T, T ]

With this we can check whether the values contains a value in O(1) time- since all we need to do it visit that index and check for T/F.

Now that we have a super simple example set-up a problem becomes clear-- what if the values contained a large number (ie 100)? We would have to fill the array with 90+ more values or F before we could indicate T at index 100. Obviously this is completely inefficient- so in order to get around this we need to come up with a way that the length of our array can better correspond to the actual number of values it represents. A common example of how we could manipulate our values to fit within a smaller array is to take their modulo ten and use THAT as the index in which the T/F will be stored.

Our new set of values contains : 1, 3, 4, 77 , and 100
77%10=7 and 100%10=0 so those indices will now contain T

Values: 100    1     3  4        77        
   Arr:[ T, T, F, T, T, F, F, F, T, F, F ]

Now that we've seen this- lets make our array a bit more complex, and actually store Key/Value Pairs within it to better reflect the actual value of the whatever is contained at a given index- just seeing that 0/7 are T doesn't do a good job of reflecting that the underlying values they represent are 100 and 77.

Since this is an under the hood look of how an Object is implemented- we can't just use an Object for this-- instead we will use another array where the first index is the key and the second is the value

Our new collection contains : 1, 3, 4, 77 , and 100

 Arr:[ 
    [100,T], 
    [1, T], 
    F, 
    [3, T], 
    [4, T], 
    F, 
    F, 
    F, 
    [77, T], 
    F, 
    F ]

Now let's add a 17 so we can see another problem: COLLISIONS. With our current system we decide where something is stored based on it's modulo 10-- so now we have two conflicting values that both want to be stored at index 7 (7 AND 77). Instead of overwriting the 77 we can just add another Key/Value pair array to index 7. Storing multiple values at one location like this is called SEPARATE CHAINING- and is just one of many ways to handle collisions.

Value at index 7
    [77, T] ------> [ [77,T], [17,T] ]

This is cool- but it's awfully convenient that our values are numbers-- what would happen if we wanted to do something like this but with strings? In comes actual HASHING- the process of taking a value and converting it to some sort of numeric code that represents it. In reality Hashing is done via some very complex math that you can look into on your own but ultimately it is just the process of converting something into a numeric code.

Now let's pretend our values contain the strings "Dog" and "Cat" with dog's value being a 5 and cat's being a 3. An example of a fake hashing function would be to use the combined ASCII value of each character in the string to determine its hash code. I'm feeling lazy so we will PRETEND that the combined ASCII value of 'Dog' is 31 and 'Cat' is 23.

Cool- now we would just make another array and store the values at the proper index. Once again we'll use %10 so as to keep our array down to only ~10 length-but now we will be using the actual hash code to determine where to place our animal strings-- Dog will go to index 1 and Cat to Index 3

 Arr:[ 
    F, 
    ['Dog', 5], 
    F, 
    ['Cat', 3], 
    F, 
    F, 
    F, 
    F, 
    F, 
    F, 
    F ]

The big thing here is that via an actual hash function we can turn ANY type of data into a numeric code- and then use that code to place it within our array. We can then access the data in 0(1) time using the proper index (though it can take more if we have multiple values stacking up in one location due to separate chaining)- which is far more efficient than traditional looping.

One last concept to look at is what is called Load Factor (represented w/ a lambda). What would happen if we had a collection of 1000 strings to store? We already know that we want to keep the length of our array in check-- but what will end up happening is that we will end up with a bunch of values within each index due to separate chaining-- and if we allow THAT to happen then we'll have slowed our hash table down which defeats the whole point. Load Factor is the idea of maintaining this balance and is calculated via:

Load Factor = (number of Key/Value pairs) / (length of array)

When utilizing separate chaining we always want a Load Factor of 1 or below (that is the length of the array is always greater than or equal to the number of pairs it stores). Utilizing this concept we can resize our array whenever this balance is our of proportion.

...And that's it- a super brief overview of the inner-workings of a hash table.
The takeaway from all of this is that instead of just storing things in an Array/List and looping through it over and over- we can go the extra mile by hashing our data and placing it into a specific index. This bit of extra work pays off when we can quickly go and find our data down the line.

To boil all of this down into a sentence-- a hash table is just an array of key/value pairs that uses complicated math to determine WHERE/HOW to store that data so that it can be quickly accessed later.

Like so many things in the world of coding--it's basically just an array- but hopefully this post has helped a bit to demystify what a hash table is AND why it's used.

Thanks for reading and please leave any questions/comments!

Thanks-

Logan

Memory, Reference Semantics, and Life in Our Solar System

loganwohlers — Thu, 25 Apr 2019 19:19:41 +0000

My goal with this post is to provide a high level overview of one of the more intimidating concepts for people new to coding- reference semantics. When I was first learning how to code- I found this topic to be very difficult and I didn't even bother with trying to understand how memory in a computer worked. Recently I've put in some effort to understand what is happening under the hood and why things work they way they do. This should (hopefully) serve as an easy introduction to some of these concepts. I fell into the trap of thinking of these as non-practical material that you might only see in an interview or in a classroom setting but I've found that even a basic understanding of these concepts has translated well across a multiple languages (as well as helping out with more advanced data structures such as linked lists/binary trees) and has made my life much easier.

Lets start with a brief attempt to demystify reference semantics- the topic of pass by reference vs pass by value. Ultimately this idea covers how variables are stored and modified in a project and aren't too complicated- but are often presented in an overly confusing way. In the most simple terms possible memory in a computer is like a giant "array". Each "element" holds one byte of data and has a memory address (think index in an array) that starts from 0 and works its way up. These addresses are referred to in hexadecimal which is why if they look like 0x11cee8 as opposed to the normal numbers we know and love. So with this in mind we have to take a look at what each of these elements can actually store. With just one byte of storage space- each element can only store a simple primitive value (characters, numbers, boolean values, etc). Different languages define their own primitive values but they mostly overlap. Multiple elements of memory in a row are how we get more advanced data structures like arrays and objects- this fundamental difference between primitives and more complex data structures is the key behind reference semantics.

PASS BY VALUE

let x=5;
let y=x;

function changeX(x) {
  x=x+1;
  return x;
}

x=changeX(x) //x is now 6
console.log(x) //prints 6
console.log(y) //still 5?

When we declare a variable in our program- a chunk of memory is carved out somewhere for that value to be stored. However all primitive values are ALREADY stored in memory somewhere- these are values our computer knows about and that don't change (ie we aren't creating a new letter in the alphabet but an object or an array can store anything). So when we create a variable and set it's value to a primitive- our computer says- "oh I know this value and where it is stored- here's a copy of it to use for your variable" the key here is that the variable contains a COPY of that value.

in the example above:
-we carve out space in memory for variable 'x'- it gets passed a COPY of the int 5

-we set y equal to x. it ALSO gets passed a COPY of the int 5

-we change the value of x to 6- but it doesn't affect y. They both started with copies of the number 5 and have no relation to each other- so changing x had NO EFFECT on y.

Now lets try the same thing with an object..

PASS BY REFERENCE

let person1={name: 'logan', age: 24}
let person2=person;

function agePerson(person){
  person.age=100;
}

console.log(person) // { name: 'logan', age: 24 }

agePerson(person) //person's age is now 100

console.log(person) // { name: 'logan', age: 100 }

console.log(person2) //also changed? { name: 'logan', age: 100 }

This time the person object DID change-- but this code is the exact same as the above example- so what's happening here? When a variable is declared for an object/data structure the computer says something along the lines of-"I have no idea what you're going to put in here but here's some space and the actual memory address so that you can interact with it again later"- it passes us a REFERENCE to a variable's actual location in memory.

-Both the person1 and person2 variables simply contain a REFERENCE to the underlying objects memory address- they DON'T STORE SEPARATE COPIES OF IT'S VALUE.

-This reference is just the hexadecimal address where the object is stored in memory. So when we change person1 via the age function- the underlying object (what person2 ALSO points at) IS changed- thus the change is reflected in both variables.

When you pass complex data structures as variables- changes made will affect the actual underlying object since we have a reference to it's underlying memory address. This is why we often make copies/have to be careful when modifying these to assure that we don't destroy/unintentionally modify their values. With primitives- no such caution needs to be taken. Reference semantics are responsible for all of it. Hopefully someone out there found this helpful. Please let me know if any questions/comments!

Helpful readings
simple examples of the "array" that is memory:
https://www.cs.utah.edu/~germain/PPS/Topics/memory_layout.html

very detailed post with more complicated examples of reference semantics:

https://codeburst.io/explaining-value-vs-reference-in-javascript-647a975e12a0

Thanks,

Logan

Bracketology and Binary Trees

loganwohlers — Mon, 01 Apr 2019 22:22:36 +0000

Last week for a project my partner and I built a bracket simulator site in Rails that seeded fake players/teams using a gem called Faker- and then randomized their stats before seeding a bracket. This week I wanted to highlight some of that code- as well as some new tweaks I've made that allow brackets to be created recursively via a binary tree. Seeding a bracket turned out to be easy- but creating the actual appropriate matchups ended up being a bit of nightmare.

The ultimate goal in the project was to create an array of all teams- ordered by matchup in an actual bracket- remove the first two teams and have them "play" and enqueue the winner- so with that approach in mind I'm going to run through the difficulties in actually ordering a proper bracket- for reference, a properly seeded 8 team bracket in array form would look something like:

[1,8,4,5,3,6,2,7]

This order would result in the proper matchups being played in the first round- as well as their proper placement within a bracket to ensure later rounds would play out correctly.

Lets start with the original idea that flopped almost instantly- we created an array of all teams based on their "power score" ordered from highest to lowest- to get the proper matchups all we did was iterate through the array and pull the first available team and the last available team- and while this worked for creating the proper matchups- it failed miserably in actually creating a bracket- as the 1 and 2 seeds wound up meeting in the second round- as opposed to the finals. what this resulted in:

[1,8,2,7,3,6,4,5]

Correct matchups but in the wrong order- ie the winners of 1v8 and 2v7 would play in round 2 (as opposed to round 3/finals)

After many brackets were drawn some patterns were found:
-In the first round the two teams seeds always add up to the number of tourney entrants+1 (ie in an 8 team bracket the seeds at to 9)

-Going off of the above you can find an opposing matchup by doing
(entrants+1)-current seed

-The number of rounds played in any tournament = log2(entrants)

With the above in mind- expanding a bracket became possible

-To make a new round we would take a seed and find what it's matchup if the bracket size was doubled- so going from a 2 team to 4 team tourney- the 1 team would now play the 4 seed (calculated via #teams*2+1-seed (2*2+1-1 in this case) which comes to 4. The same math on a 2 seed results in them playing the 3 seed).

In our project we used this process to create an array of matchups- starting w/ a seeded 4 team array and expanding it however many times needed to meet the number of entrants:

def double_bracket(bracket)
    doubled_size=bracket.length*2
    doubled=[]
    bracket.each do |seed|
        doubled.push(seed)
            doubled.push((doubled_size+1)-seed)
    end
    doubled
end

def bracket_order(entrants)
    starting=[1,4,3,2]
if entrants==4
        return starting
    else        
        for i in 1..(Math.log2(entrants)-2)
            starting=double_bracket(starting)
        end
    return starting
    end     
end

Then with a correctly ordered array of seeds (bracket_order) we could map our array of ordered team objects (ordered_teams) onto it- to get a final array containing team objects in proper order- that would then be used to simulate a tournament

def map_bracket (ordered_teams, bracket_order)
for i in 0..(bracket_order.length-1)
  team=ordered_teams[(bracket_order[i]-1)]
  bracket_order[i]=team
end
    bracket_order 
end

However we don't think about brackets like an array- we think like this (maybe turned 90 degrees)

                     [1, 2]---------------------2
                      /   \
                 [1,4]     [2,3]----------------4   
                 /  \       /  \
             [1,8] [4,5] [2,7] [3,6]------------8

-looks awfully similar to a binary tree...

Binary Trees and Recursion

I attempted to replicate the above in Ruby with binary trees- using an array of each matchup as the node data.

To start I created a BracketNode class and a BracketTree class

class BracketNode
    attr_accessor :data, :left, :right
    def initialize (data=nil, left=nil, right=nil)
      @data=data
      @left=left
      @right=right
    end
end

class BracketTree
  attr_reader :root
  def initialize (overall_root=nil)
    @overall_root=overall_root
  end 
end

Then I initialized a node with the [1,2] matchup to be used as the root and expand recursively from there.

def build_bracket(node, entrants, curr_level)
    if curr_level<=Math.log2(entrants)
        node.left = BracketNode.new([node.data[0],((2**curr_level+1)-node.data[0])])                                      
        node.right = BracketNode.new([node.data[1],((2**curr_level+1)-node.data[1])])                    
        build_bracket(node.left, entrants, curr_level+1)
        build_bracket(node.right, entrants, curr_level+1)
      end
  nil
end

It looks a little ridiculous- but it's all the same patterns from above- taking seed of each matchup and subtracting it from log2(entrants)+1 to find their opposing seed- this time recursively building bracket nodes as opposed to pushing into an array until desired # of entrants is reached.

Then there were a few helper methods- one to count the height of the tree and another to print all nodes on a current level- by combining those the below function prints all the matchups with a line between each round

def print_all_levels (node)
  h=self.height(node)
  for i in 1..h
    print_level(node, i, 1)
    puts "----------------------"
  end
end

The final code run to actually create a BracketTree and print it's matchups looks like this for a 64 team bracket

root=BracketNode.new([1,2])
bracket=BracketTree.new(root)
# #start on level "2" as level 1 is the [1,2] (aka the 'final')
bracket.build_bracket(root, 64, 2)
bracket.print_all_levels(root)

It was fun to try and use binary trees again as they are nowhere to be found in ruby- building the bracket tree recursively ultimately served as a great challenge and reminded me once again of the power of recursion. Please leave any feedback or room for improvement in the actual code if you see any!

Thanks for reading,

-Logan

Link to bracket simulator: https://github.com/loganwohlers/Mod2Final

Automating the Boring Stuff in Rails (Rails Snippet Pack v1)

loganwohlers — Tue, 19 Mar 2019 23:16:06 +0000

Before starting on the path to software development I worked in finance- which really meant I worked in Excel. A lot. Every day spent in spreadsheets sometimes exceeding 10,000 lines- every one of them belonging to an account with hundreds of thousands of dollars invested (at the minimum). Needless to say I had to get fast in excel- so I learned every keyboard shortcut and workflow process I could (it was my inability to actually write/automate the most inefficient processes that eventually drew me to coding) and it worked- I got really really fast. But since I've moved on to writing actual code in a text editor I'm slow. I was flying too close to the sun back in Excel- now I feel like molasses half the time I'm working on any new projects. Now to be fair- a bunch of this stuff is strictly muscle memory (I couldn't tell you the excel shortcuts I used- my fingers just knew)- but more than that it's also leveraging the tools available so that you can spend more time on the thinking and less time on the grunt work that is typing out an HTML form.

With all this in mind I've been making a conscious effort to speed up my code by utilizing hotkeys/shortcuts (s/o to my colleague Brian for his post on useful keyboard shortcuts- you can read that here- many of them work in conjunction w/ the rest of this post: https://dev.to/bouhm/you-should-be-using-keyboard-shortcuts-2poe) and I can already feel it making a big difference. Then I started working in Rails- typing the exact same form and controller syntax (since as a class we've been banned from using rails' scaffolding) and then Rails having the audacity to expect you to wrap everything '<%=' and '%>' (squids and ice cream codes- as they say in the industry) was driving me insane. Creating a simple RESTful route flow took way too long- so I eventually turned to snippets. I've seen and used them before (mainly in HTML) and they are objectively amazing- but I was having trouble finding ERB ones that would work well in rails- and even then I wanted stuff that was tailored for the kind of text I found myself typing over and over. The problem with snippets in my opinion though is that they are weird and the syntax is pretty unfriendly for a beginner:

Seriously what is this? I just want to add some squids and ice cream cones!

However it all clicked when I found- https://snippet-generator.app which immediately removed the barrier to entry and allowed me to start taking work I had done and turn it into snippets. Once I made a couple useful ones I couldn't stop- so I tried to compile a list of them that would not only be useful to myself- but to all of my classmates/fellow Flatiron students working through the second mod curriculum. For now it's not much- but it's certainly something that has sped up my flow tremendously and something that I will add to as I continue running into the same issues time and time again (plus with the generator they are VERY easy to write)- the next step from here will be to look into real automation of tasks- mainly via scripts. I want a push button start on my programs and working towards that continues to be a fun experience.

link to github page w/ the snippets- more to come soon
https://github.com/loganwohlers/Rails-Snippets

Thanks for reading! Please leave any feedback and suggestions-

Logan

Moneyball in Ruby- a first attempt at a bare bones stat driven model

loganwohlers — Tue, 12 Mar 2019 00:53:38 +0000

Credit- ESPN

Predictive modeling and statistics have always been of interest to me. Before getting into coding I studied finance- so I've been exposed to many statistical concepts, but mainly through the lens of portfolio theory. However, for most people (myself included) statistics and their importance are much better digested through the world of sports. Basketball in particular is still very much in the middle of an analytics revolution- with content on advanced statistics more readily available than ever. For a while I've had the idea of creating some sort of model in the back of my mind - but before I could have only built something using excel- which would not have been as satisfying as trying to build something with actual code. Now that I can actually write code-for this first post- I decided to see what I could do in Ruby from scratch- starting with finding a stats framework on the basketball side of things and then seeing if I could re-create some semblance of it within a program.

So which stats are particularly useful as predictors of team success? Are there any inefficiencies that the market hasn't accounted for? Obviously this question goes infinitely deep, so to start I wanted to see if I could find some sort of commonly accepted framework that wasn't too overwhelming for someone like myself who is not fully versed in the world of advanced statistics. I came across Dean Oliver's Four Factor's of basketball success (you can read more about them here: https://www.basketball-reference.com/about/factors.html).

The four factors break down four areas in which basketball games are won- weighted by their significance. The factors are :

Shooting (40%) measured w/ eFG%
Turnovers (25%)- measured w/ TOV%
Rebounding (20%)- measured w/ ORB% AND DRB%
Free Throws (15%)- rate calculated by FT/FGA

(note - the "four" factors are actually composed of eight different stats -measured for both offense/defense. Defensive rebounding (DRB%) is the only explicitly different stat between offense/defense)

So with that framework to go off of the next step was to actual grab some data to work with. I couldn't find a free API that provided all of the stats I was looking for- so I turned to data from Basketball Reference (https://www.basketball-reference.com/)- which is an amazing resource of every stat you could think of going back 50+ years. Even better- they actually provide a Miscellaneous Stats table that specifically includes the four factors. I exported the table as a CSV and read it into Ruby- along with making a method to rip the column headers from the table and use them to create a hash of all the statistics with their labels.

Helper method for breaking down CSV table into a relavent hash

Now how does this data get modeled? Can we test whether the four factors are actually a legitimate way of looking at how games are won? I'm going to reiterate here that I am in no way a statistician- so I once again consulted the internet to find an example of the four factors in action - and came across another blog that demonstrated some of the math used in the statistical analysis (all credit to Justin Jacobs https://squared2020.com/2017/09/05/introduction-to-olivers-four-factors/). The post provided a great example of how to try and use the data by doing a linear regression to model the relationship between the factors and a team's total wins. With an idea of where to take the data- I tried to then duplicate the result within Ruby.

Matrix-like code of the stats w/in the hash

To start I pulled a new table down- using data for all the teams from the 2016-17 season so I could compare my results to Justin's blog. I stripped the data in my hash down to just those relevant to the four factors- as well as adding data for win total- then I found a gem called 'eps' (https://github.com/ankane/eps) that would let me perform a linear regression in Ruby. I ran the regression on my hash using wins as the dependent variable and came out with data that was nearly identical to Justin's figures (slight variation due to minor differences in data used). To summarize the results- all of the coefficients pointed in the right directions (ie offensive points scored impacted wins positively and turnovers impacted negatively) and the the r² was 0.896- indicating a pretty high correlation between the four factors and a team's win total (seriously- read the blog post if any of this interests you for a much more thorough description with graphs and math shown)- but the most important part was that the model was able to accurately reflect reality!

running the regression on the four-factors hash with resulting coefficients

To wrap this up with some final thoughts:

It was humbling to dive into the world of statistics like this and see just how deep even the most 'simple' stats and frameworks can go. The reality of these analytics is much like the stock market- with everyone looking for any inefficiencies- whether it's someone on a team's analytic department deciding on a team's draft pick or a professional better looking for opportunities in the lines. Just like coding/development this is one of those topics that feels infinitely deep- but trying to bridge the gap and bring the model into reality with my own code was very fun- better yet is the room for improvement- even in just this tiny thing I built. A few weeks from now I'll look back on this and be able to do so much more.

I don't think I'm the next Billy Bean- and I certainly wouldn't put any money on the line at what this model spits out (it doesn't even DO anything!)- but gathering statistical data like this and making use of it is definitely something I plan to work on more in the future. Just in this exercise I came across so many new concepts I'd like to learn and implement (ie machine learning). But those are for a another time- I will definitely be revisiting this in a few weeks at the latest and will have improvements ready.

Thanks for reading and please share any feedback!

-Logan