Ichiro, Sweaty Bats, and Optionals

First off, congrats to Ichiro Suzuki on his 3,000th MLB hit on Sunday! A triple at that! Four years ago David Waldstein (@DavidWaldstein) of the New York Times wrote this great piece about Ichiro and his bats. In the article, Waldstein talks about how Ichiro chooses his bat based on the humidity and the bat's weight that given day.

Can you imagine if all hitters logged the weight of the bat they used everyday for an entire season? After seven game days in a row we might see that the constant bat weight may have something to do with the player's fatigue and advise a lighter bat as the week goes on or depending on the stuff of the opposing pitcher. 

So let's say we created an app that allows hitters to track their slugging percentage on different amounts of rest and different weights of bats. At first we want to establish a baseline so let's have the user use the same bat weight for a month of games.

After a month we get this data using the same 30 ounce bat:

Slugging percentage after a day of rest =  0.433

Slugging percentage after no rest for two days = 0.442

Slugging percentage after no rest for three days = 0.453

Slugging percentage after no rest for four days =  0.441

Slugging percentage after no rest for five days = 0.427

Slugging percentage after no rest for six days = 0.412

Slugging percentage after no rest for seven days = 0.392

So the first day back after a day of rest the hitter hits well, but really peaks on the third day. After that, the hitter starts to show signs of fatigue (this, of course, does not account for the different pitchers the hitter faces and is all completely hypothetical). 

That gives us a baseline of data. With that data in mind, let's have the hitter adjust his/her approach to what weight bats to choose on which days of the schedule. 

var batWeight = 31, slugging percentage after a day of rest = 0.438

var batWeight = 31, slugging percentage after no rest for two days = 0.446

var batWeight = 30, slugging percentage after no rest for three days = 0.459

var batWeight = 29.5, slugging percentage after no rest for four days = 0.451

var batWeight = 29, slugging percentage after no rest for five days = 0.442

var batWeight = 28.5, slugging percentage after no rest for six days = 0.435

var batWeight = 28, slugging percentage after no rest for seven days = 0.427

Much better! 

But what if the hitter forgot to track a day, forgot to put in what weight bat s/he used and how s/he hit that day and we still tried to run the program? What do you think would happen? We'd have an error and the program wouldn't run messing up our entire experiment. 

Other than goofing the hitter so s/he doesn't do that again, how can make sure that the program continues to run? Fortunately for us, Swift offers us a chance to do this through optionals. 

When do we use optionals?

Anytime you ask a user to input information, be it the number of hits they got that day or the weight of the bat they used that day, there is a chance they won't put the info in. This is when we want to make sure we declare our optionals. 

How do we declare optionals?

In the beginning of our program, we lay out our variables and constants. This is a good time to declare our optionals. In our case, they look like this:

See the ? after our declared data type, Double? That ? declares that that Double, absFirstDayAfterRest for example, is an optional. We make "at bats the first day after a day of rest" because there is a chance the user will forget to enter how many at bats they had that day. 

How do optionals work?

Instead of returning an error when a program comes across an empty value (e.g., no at bats or hits logged), a Swift optional returns nil as you can see in the example above. What is nil? Good question. Nil is a rather abstract concept and can become confusing rather quickly. 

Think of nil like Eddie Gaedel pinch hitting for Josh Donaldson who had too many tacos last night and is now paying the price: We expected Donaldson to bat (akin to entering a value), but instead he's "occupied" and we get Gaedel (nil). Sure, Gaedel's going to bat, but chances are he's not going to get a hit, but at least the game will continue. What would happen if you didn't send anyone up to bat? The ump would assess an out, the manager would blow his stack, would argue with the ump, chew out his own players, and the game would go nowhere. At least with nil the game continues. 

Why are optionals important?

Nil helps us keep playing the game as opposed to nothing which is like sending no one up to bat and getting us an automatic out (e.g., an error that stops the program altogether). We can work with nil, we can't do anything with nothing.

That's a good place to stop for now. Optionals aren't easy and there's more abstraction to come.

On Deck: Optional binding.