Back to school I go. It's been a while since I took notes, studied for exams, and was made to take attendance (Really? Are we still forcing adults who willingly pay boatloads of money for an education, only to infantilize them by ensuring they are physically present at the start of class? I digress...).

Turns out there are some interesting things happening in modern Statistics. I'd like to pull back the curtain and share some lessons with you all. Today, I'm going to (re)introduce the concept of probability in a more modern way than you probably remember learning in school, beginning with the canonical example: the coin flip. 

Say we flip a coin 3 times and get 3 heads. If I asked you if this coin is weighted or fair, what would you say? More specifically, what's the most likely estimate for the probability of getting a heads on a given toss? Most people would still say 50%. Sure I got 3 heads in row, but thats perfectly reasonable (1/8 chance in fact). Big deal, dataman. 

And you'd be exactly right.

Classical statistics, however, would say the most likely value for the probability of heads is not 50%, but rather 100%. This method naively says, "Since all I've seen are heads, then I'm putting all my money on the next toss to be heads." This method would clearly lose all its money after a few rolls at the casino. Here is what's happening graphically:

Likelihood function. The highest point (maximum) of the function corresponds to the best guess for my probability.

This is about the point where rational, non-math nerds get off the stats train and we lose you guys forever. Because that doesn't make sense.

Even if the coin was biased, I'd need more than 3 measly tosses to convince me that it's 100% in favor of heads. Enter modern data analysis methods.

Let's pretend I was a reasonable person who saw a coin on the table and figured it was - like every other coin I've ever seen - not weighted. That is, I thought that the probability of landing heads was 50%. Then I flipped the coin 3 times and got 3 heads. This probably doesn't do much, if anything, to change my views. The coin is probably still fair. Maybe if I saw 6 heads in a row, or 10 heads in a row, I'd be more likely to believe something is fishy. So in light of my 3 tosses landing heads, my belief remains that the coin is most likely fair. In other words, I would NOT put all my money on heads.

If you understand the logic I applied above, then you basically understand Bayesian inference. It all boils down to*:
1) having a belief about something before it happens (in this case, believing strongly in a 50/50 fair coin)
2) seeing something happen (3 heads in row)
3) updating your belief about that thing in light of the evidence

Check it out:

Bayesian updating: as we observe more and more tosses, we update our beliefs about the probability of heads.

It's pretty intuitive isn't it? It's also the hottest new thing in statistics, if such a thing exists. This type of statistical reasoning, which has been around for centuries but for technical reasons has not become mainstream until the last 20-30 years, underlies innovations such as image processing, recommendation systems, signal processing and spam filtering, to name but a few.

What a great time to be in data!

* the other key ingredient is defining a loss function but that's not necessary to drive the point home. Technically speaking, your belief (or action taken) should be that which minimizes the posterior expected loss.

Please comment on the article here: The Data Game - Ilan Man

The post College redux appeared first on All About Statistics.

Who doesn't love a good top 10 list? They're short, easy to read, and for the sake of us not having to think too hard, have already decided the answer for us. A favorite top 10 genre of mine is the top 10 cities list. We've all seen them - cheapest cities, most outdoorsy, booming tech scenes, etc... We search for our city in those lists and feel great when it is listed. When it isn't, we question the lists validity. Perhaps even our own. But, I would never base where I'd want to live solely on some list since more likely than not, a generic list will miss certain criteria that are important to me.

I bring this topic up because as many of my fans know, my wife and I are moving to Durham, NC in a few weeks. But what they don't know, what keeps them up at night, is why?

So instead of pointing them to some random top 10 list that Durham happens to be on, I outlined a number of considerations that are important to my wife and I in determining where to live. These will be inputs to my Overall Best Urban Center for Ilan and Ruti Index, aka OBUCFIRI, aka BCIR.

There are plenty of great cities in the U.S that we would consider living in, but for the sake of brevity, I narrowed it down to Austin (AT), Durham (DH), San Francisco (SF), Denver (DV) and New York/Brooklyn (BK). Since Durham is much smaller than the others, to even it out, I included the Raleigh-Durham-Chapel Hill area (RDU) as a proxy. It's totally legit. Also, since these cities have a lot in common - think farmers’ markets, young & liberal people, coffee shops with Edison lightbulbs, diverse neighborhoods, tech opportunities, etc... some criteria is a wash and I skip over it.

On to the inputs...

1. Fitness - "easy access is the best kind of access" (Man, Ilan; September, 2010)

For us, easy access to nature is important: we like to run and bike outside - so good weather and quick access to low-traffic areas are huge. A varied elevation profile and a swimmable body of water are both wins.

As it relates to interesting places to hike and bike, Brooklyn draws the short stick. To get to the nearest quality ride, I need to leave Brooklyn, head North West across Manhattan and enter Jersey via the GWB! Just getting there takes me over an hour, and to bypass crazy traffic this needs to be done no later than 7 AM. There are only so many loops you can do around Prospect or Central Park before you start getting dizzy, and while New York has tons of bike lanes, that doesn't mean that everyone adheres to the rules. But I digress…

San Francisco certainly has a bike friendly culture. And a swimmable body of water. However, sans wetsuit, the ocean is really cold!

The Mile High City, on the other hand, is a haven for these types of activities, especially bikeability and cycling in general, since it has a few hills not too far away. And I think skiing is a thing. Durham has a surprisingly large number of hiking and running trails and at least makes the list for bikeability. And for weekend trips, it has access to mountains and a body of water. Austin has a large number of rides around the city, of various elevation and distance.

Related to fitness (and culture, and transportation) is a city's walkability. New York wins (no need to look this up), but how do the others rank? I used this site to figure it out. It's pretty neat because you can input the zip code of your city to get neighborhood level results. Durham, for example, has a walk score of only 28, but the zip code around the downtown has a score of 83 - very walkable. The same is true of sprawling cities like Denver and Austin.

Fitness Score: Bike score + # of mountains and swimmable water within a 1 hour drive + # of hiking/biking trails (per the respective city website) + some arbitrary amount based on what I think.

2. Cost of living - "it's fun when things cost less"

This site provides a detailed breakdown of various cost of living items, and allows you to compare cities. For example, 16 oz of local cheese in Durham is $4.83 compared to $10 in New York, and $9 in San Francisco. Obviously the hipsters are driving up the prices.

In Denver, you can get a pair of Levi's for about $8 less than in New York. Also, compared to New York, beer in the supermarket is slightly more expensive in Durham, but a bottle of beer at the bar is cheaper. And milk seems to be more expensive in Durham. 

Another important factor - the price of a bowl of ramen. Here in Brooklyn, we go to Chuko for our fix, where the ramen is $13. Turns out that Dashi Ramen in Durham also has $13 ramen. In Austin, however, it's closer to $9.

It's all a bit moot, however, when you consider the difference in rent. Monthly rent for a furnished 900 square foot apartment in a so-called expensive area: in Durham is $1,580 and in Austin $2,100. In New York? $3,600. That's my first sign of suspicion in this data - there's no way the rent's that cheap in New York.

COL Score: Accounting for the expenses above with averaging some other sites, the COL scores are (lower is better):

3. Friends - "facebook friends don't count."

Friends are an absolutely integral part of our lives. Friends make everything better. Technically they make things exponentially better.

Because we need a data chart.

Living outside of New York or Toronto would force us to make new friends. Luckily, we already have friends in San Francisco, Denver and Durham. Sorry Austin, you lose.

Friend Score: 1 + the natural logarithm of the # of friends we have in that city, rounded up.

4. Culture - "funk parties, farm shares, liberal people, performing arts, history, community"

As far as I'm concerned, it's near impossible to beat NYC/Brooklyn on this. I know that it's full of transplants and hipsters and many say devoid of its own culture, but according to the way I define it, it's the bees knees (1920s slang - perhaps the only thing we have in common).

We all know about SXSW and Austin's burgeoning farmer's market scene. Ok I kinda made that last one up, but apparently its true. 

Durham has a recently built performing arts center, a music scene and good southern food. DH also ranks pretty high on the farmers market list.

I'm also pretty biased towards the East Coast, with its older history and more diverse communities. Having said that, I'm sure Denver has its own culture. And San Francisco is a cool place too.

Culture Score: # of music & art venues (easily Google-able) + (20 ÷ ranking on some "best of" foodie list) + the "city-wide diversity index" + 10 points if the state went for Obama in 2012 (+5 if a swing state).

5. Weather - "damn you the entire North East!"

This one is pretty matter-of-fact. New York blows wet, dirty and useless snow.

Durham is nice, albeit too hot and muggy in the summer. Austin has great weather - though it too is considerably hot in the summer. Denver is great because of the sun and seasons. San Francisco is perpetually almost really good.

Weather Score:

1. +1 for every month between 50 and 90 degrees, -1 for every month below 50 and above 90
2. (100 - Annual precipitation (inches))/10.
3. 20 - # of days with new snowfalls. Denver gets pass. The snow there is amazing and functional. Though to be fair, we don't ski.

6. Vocations - "we work in tech"

Since we couldn't live in a city without some tech, this category is pretty straightforward. San Francisco has the most, New York has a ton, but it appears so do Durham, Denver and Austin. Note that the rankings are less of a commentary on tech opportunities and more of a commentary on where to live (COL, jobs, lifestyle) if you happen to work in tech.

Vocation Score: (30 - the average ranking from these two lists) + 20 points for every top notch university with a strong CS or Statistics program within an hour (sorry Boulder, you're too far in rush hour).

7. Transportation Infrastructure - "cars bad, bike lanes good"

We also love to travel. Austin and Durham make this list for best airports. New York, on the other hand, has 3 huge international airports, but for a number of reasons, all 3 make the 10 worst airports list. 

Car traffic sucks. Many weekend destinations are decided, in part, upon whether I could get there without having to enter Manhattan. If you've ever had to go into the city on a weekend and found yourself in lower Manhattan, you know what I mean. However, it appears that Austin is just as bad, along with San Francisco, and Denver isn't far behind. Raleigh-Durham definitely has the least amount of traffic. Benefits of being smaller.

Lastly - public transit. Again, New York is the clear winner with its very accessible subway and bus system (except for the G - but who really needs to shuttle from South Brooklyn to Williamsburg anyway?) San Francisco has the BART, and Durham barely edges out Denver, both of which easily beat out Austin on this list.

Transportation Score: +10 for every international airport. +5 if it's on the "best airports" list and -5 if it's on the "worst airport" list . +(100 - composite traffic index). +(Trips per capita/5)

Formula time

Now with all of the considerations out of the way, time to calculate the Overall Best Urban Center for Ilan and Ruti Index, aka OBUCFIRI, aka BCIR. 

BCIR = (Fitness - COL + Culture + Weather + Vocation + Transportation)*Friends

Before we tally it up, you'll notice that Friends are multiplicative. Remember, they matter a lot. But since where you live will likely be skewed too high, I'm going to ignore that for the final tally. Just know, however, that Friends would have been very important.

Final tally:

• Durham: 277
• Brooklyn: 231
• Denver: 206
• Austin: 204
• San Francisco: 189

Pretty tight! Durham is the clear winner, with Brooklyn taking first runner up. Interesting that Denver and Austin get essentially the same rating but are quite different places. Sorry Silicon Valley, maybe if I counted Oakland it would've shook out differently.

And with that, we bid farewell to Gotham and get ready for new adventure down South!

P.S. This is absolutely not how we decided where to live, but it's vaguely similar. Getting into Grad School also helped.

Please comment on the article here: The Data Game - Ilan Man

The post Slowing things down appeared first on All About Statistics.

Since 1985, the NFL Combine has taken place in late February, a few weeks after the big game. This year it began on February 17th. The Combine is a place where NFL executives conduct a multi-day interview to determine who they will draft in the upcoming year. During this time, collegiate football players partake in physical and psychological activities, including a short interview with NFL teams to make their case.

Many consider the most important information gained from this event to be the interview, psychological tests and, perhaps some show of physical talent. However, teams have already done their homework and studied game tape which becomes the predominant factor in their decision making. Specifically, they don't put too much stock on the physical tests, because results in the Combine are not strong predictors of success in the NFL (the counter factual is also true - having a bad Combine does not imply poor NFL performance). So...case closed?

Kind of. But since we have the data, let's see if we can predict whether or not a player will get drafted solely on their stats at the Combine. If we can get a reasonably working predictive model, we can use it to predict 2015 drafts!

First, some boxplots, because you know you wanna...

Distribution over time of the height of a players' Vertical - basically, how high they can jump straight up.

Looking at the Verticals for Quarterbacks, Running Backs, Corner Backs and Wide Receivers shows us that the data is pretty consistent over time, except for a few outlier players, which are to be expected. And 2008. I bet I know whose fault that was.

So given the consistency in athletic performance, controlling for position, can we build a model to predict if a player gets selected? I wouldn't be writing this thing if we couldn't.

I trained an ensemble of models* on data from 1999 - 2011, and attempted to predict whether or not a player would get drafted in 2012 and 2013**.

The first thing I looked for was significant variables. Turns out, that the only physical activity of any import is the Forty Yard Dash. One of my models, a Decision Tree, selects the variables which split the data into the most informative buckets:

The higher up the variable is in the tree, the more important it is in categorizing players.

This doesn't imply that having a good Forty will mean you get selected, but there's a definite correlation***.

For some positions like Wide Receiver and Corner Back (not shown below), the model categorized pretty well. For other positions, such as Quarterback and Running Back, the model did slightly better than guessing.

Models used in Confusion Matrices were, in order, Logistic Regression, Logistic Regression, Random Forest

As you can see, drafted and undrafted Running Backs and Wide Receivers were more correctly classified, compared to Quarterbacks.

Visually, we can see how well a model can separate draft picks correctly using our trusty old ROC curve (hover over lines to see the position in question):

Poor Quarterback classification could be because QBs play a very special role on the team where raw athletic talent is not nearly as important as all the intangibles they bring to the team (see link above for Brady, Tom). And good looks aren't tested in the Combine.

Finally, you might think, like I did, that if Combine metrics weren't very predictive, then perhaps you could just come up with some simple heuristic to separate picks. For example, one such heuristic could be that players with (a) Higher Verticals, or (b) Faster Forty's than average, get picked. Those that fall below average, do not. Here's how such a model fares:

Just better than guessing.

Some might say this kind of simple heuristic model isn't all that bad, given how unsophisticated and quickly we put it together. This kind of model might come in handy at a party when you're making bets and need a smart decision tool very quickly (an all too common scenario). The Data Man, however, has time for models. Especially when they outperform heuristics. And it's these models that I'll use to make predictions for the 2015 draft using this years Combine.

Stay tuned for the results!

*The ensemble included a decision tree, k-nearest neighbor, logistic classifier and a random forest classifier. See here for code!
**My dataset didn't have up to date draft picks for 2014
***In addition to decision trees, I looked at the p-value on a logistic regression and it was significant as well

Please comment on the article here: The Data Game - Ilan Man

The post What’s in a Combine? appeared first on All About Statistics.

I’ve been working on the ggRandomForests vignettes pretty consistently now. I’m writing the randomForestSRC-Survival vignette in LaTeX with the knitr vignette engine. I wrote the the randomForestSRC-Regression vignette in markdown.

I’ve decided to upload the Regression vignette to arXiv for additional distribution. The arXiv submission process prefers LaTeX files, and since RMarkdown can compile to pdf, using pandoc through a LaTeX document, I was hoping for a simple way to go from Markdown to LaTeX. My idea was to generate the LaTeX source, and do a few cleanup edits before submitting.

I tried a few things, Rstudio tends to remove the intermediate tex file after compile. So I went to the rmarkdown::render command. The intermediate files were still removed.

Then I found the presentation at http://blog.rstudio.org/2014/06/18/r-markdown-v2/. The “Aha!” moment was when Yuhui said that the yaml metadata commands pdf_document, html_document and word_document are commands within the RMarkdown package. A quick help search:

> ?pdf_document

pdf_document(toc = FALSE, toc_depth = 2, number_sections = FALSE,
  fig_width = 6.5, fig_height = 4.5, fig_crop = TRUE,
  fig_caption = FALSE, highlight = "default", template = "default",
  keep_tex = FALSE, latex_engine = "pdflatex", includes = NULL,
  pandoc_args = NULL)

and there is a keep_tex argument. Suddenly, the rest of the yaml markdown syntax also makes sense.

I changed my output syntax from:

output:
  pdf_document: 
    fig_caption: true

to:

output:
  pdf_document: 
    fig_caption: true
    keep_tex: true

The Rstudio knit PDF button still removes the tex file, but using the command line render command works as I need.

Now I just need to add a few edits… and I’m off!

Please comment on the article here: Learning Slowly

The post From Markdown to LaTeX output using RMarkdown. appeared first on All About Statistics.

R testthat unit tests with GitHub, Travis-CI continuous integration and the covr package for Coveralls code coverage.

I’ve been working pretty hard on getting the ggRandomForests package wrapped up so I can work on some other projects that have as much or more potential impact. This is my second CRAN package, and I’ve learned a lot about R programming, with loads of help from the hadleyverse.

I’ve come to statistics from an engineering background, and R is not my first language. I’m familiar with unit testing, what it is and how it’s supposed to work. The advantages of writing tests first seem to be enormous, but I have not really been able to get to the “nuts and bolts” of it. How do I apply this to my work specifically?

So, I started by starting! I went through my ggRandomForests package and wrote a series of testthat tests to just make sure objects belonged to the correct class. At JSM!2014, I cornered Hadley Wickham got him to help me get the tests to run on R CMD CHECK and with devtools test() function the way I expected. So I was off and running.

Except that I really didn’t get the part about “write a test, then code to the test” part. So my test framework languished.

On Monday, I learned about the covr package. I’ve tried code coverage in the past, also without much luck. Getting things instrumented and then figuring it all out was a huge amount of work in C/C++. I’ve also briefly tried some of the R code coverage tools. The covr package has the advantage of putting a bunch of tools into the mix to make the whole toolchain work. And I am benefiting from the process.

I’ll try to briefly describe what I’ve done to implement code coverage to improve my testthat tests and hopefully make my package more stable now and as I add more features in the future.

Code coverage using the covr will require three web based tools:

• GitHub will host your R code. Hadley covers version control, and using GitHub in his R Packages book. Look at the Git and GitHub chapter.

• I was already using Travis-CI for continuous integration. You set up this site to watch your GitHub repository, and test your package at every git commit. I’ve caught some silly dependency bugs with this, because I’m using development versions of R packages that are not widely available yet. I haven’t figured out PackRat yet, and I’m not convinced that is the correct solution to this particular problem.

• Coveralls is the last piece. You set up Coveralls to watch the Travis-CI build, and it will generate a report showing what lines of code you’ve actually hit… with your testthat tests.

GitHub

If you’re not using GitHub for your package development, I suggest you start. You’ll need this account to start. Create a repository for each package. Then Commit early and often. Sit back and watch the fireworks.

My workflow is to develop and write during the day, and commit changes only when I have a clean R CMD CHECK.

Travis CI

I don’t remember how I found Travis-CI, though I’m going to guess it was through either watching Hadley’s Github traffic or reading a retweet of his. Either way, setup was a breeze when I found this GitHub wiki (https://github.com/craigcitro/r-travis/wiki)

You create an account with your GitHub account. You’ll see a list of all your GitHub repos, and you select which ones you want to test continuously.

For R packages, you add .travis.yml file to your package root that tells Travis-CI how to test your package. This is (mostly) mine from the ggRandomForests package. I basically copy and pasted the default from the wiki page.

# Sample .travis.yml for R projects.
#
# See README.md for instructions, or for more configuration options,
# see the wiki:
#   https://github.com/craigcitro/r-travis/wiki

language: c

# For code coverage
before_install:
  - curl -OL http://raw.github.com/craigcitro/r-travis/master/scripts/travis-tool.sh
  - chmod 755 ./travis-tool.sh
  - ./travis-tool.sh bootstrap
install:
  - ./travis-tool.sh install_deps

script: ./travis-tool.sh run_tests

after_failure:
  - ./travis-tool.sh dump_logs

notifications:
  email:
    on_success: change
    on_failure: change

If everything is in order, you’ll now get an email on git push to GitHub whenever the Travis-CI status changes.

You can also watch as Travis-CI does it’s testing by going to the website. You’ll see why your code doesn’t build as well as other diagnostics. And you can add a nice badge to your README.md file which will be displayed on your repo GitHub landing page. The badge is updated in real time… here’s my ggRandomForests badge:

Clicking the badge will take you to the Travis-CI build page for the repo. But come back, there’s more!

Coveralls

I was happy with everything, until Jim Hester posted a devtools issue about a pull request for a use_covr() function (use_coveralls() maybe?).

So I clicked through to the covr GitHub page. The README.md file is really short, with simple instructions to get this up and running. So easy, I had to do it right then.

Basically, repeat the Travis-CI setup I did at the Coveralls website (https://coveralls.io/repos/new) and then add 2 lines into my .travis.yml file.

install:
  - ./travis-tool.sh github_package jimhester/covr


after_success:
  - Rscript -e 'covr::coveralls()'

This instructs Travis-CI to install the latest covr package from GitHub before running the tests, then run the covr::coveralls() function to get the data over to (https://coveralls.io/).

And then you can get a new badge, from coveralls!

It’s like collecting stickers!

Now what?

OK, so at writing, the ggRandomForests code coverage was at 75%. Two days ago, it was at 43%, so I’m pretty pleased with this. How did I get this improvement? By writing better testthat scripts.

I thought about screen shots, but this is long enough already. So, click on the Coverage badge, and it will take you to my Coveralls stats page for the R package (It will direct you away from this page by default). What you see is a history of all the builds I’ve done since I started the Coveralls process. The coverage badge will have an icon indicating how the coverage changed, and what the current percentage of code coverage is.

It took me a little bit to figure out that if you click on the commit message, you’ll see the report that can really help. This page lists the code coverage for each file in your R code directory. If you click on a file, you can see which lines your testthat tests actually hit.

The hard part is to figure out what test you’ll need to add to get your Coveralls number to improve. My particular case required sending in some bad objects, removing some code that I no longer needed and just thinking about what the code was supposed to be doing. I spent about a day really working on tightening up my tests, and I gained a significant increase in test coverage.

If you look at my pages, you’ll see that I have one file that has 0 coverage. That file is probably taking my coverage down from somewhere close to 90%. I am consciously choosing to not test that particular function for two reasons.

1.The function is time intensive. I think it takes about 20-40 minutes to run on a reasonable machine.
2. The function doesn’t test my package, but could be used for a test of the randomForestSRC package I depend on.

I wrote the function to make my life easier. I distribute it in case users want to create their own cached versions of randomForestSRC objects. If I remove the function, my stat goes up, but for the time being I’m OK with the lower number. At least I know why the number is what it is.

I’ll add one more link to Hadley’s books: To really improve testthat tests, I’m going to be returning to (http://r-pkgs.had.co.nz/tests.html). Just because I’ve gotten this far doesn’t mean I’m really at “best practices.”

Please comment on the article here: Learning Slowly

The post Testing, testing, testing! appeared first on All About Statistics.

Continuing progress with the vignettes mean bug fixes in the code. Plus I’m presenting the regression random forest vignette to the stats group here tomorrow.

http://cran.r-project.orgggRandomForests/index.html

I’ve got another blog post percolating that will detail the biggest change in this version (improved code testing), so here’s the change summary.

• Update “ggRandomForests: Visually Exploring a Random Forest for Regression” vignette.
• Further development of draft package vignette “Survival with Random Forests”.
• Rename vignettes to align with randomForestSRC package usage.
• Add more tests and example functions.
• Refactor gg_ functions into S3 methods to allow future implementation for other random forest packages.
• Improved help files.
• Updated DESCRIPTION file to remove redundant parts.
• Misc Bug Fixes.

As always, comments and suggestions are welcome at the ggRandomForests package GitHub development site: https://github.com/ehrlinger/ggRandomForests

Please comment on the article here: Learning Slowly

The post Another release day: ggRandomForests V1.1.3 appeared first on All About Statistics.

I’ve posted a new release of the ggRandomForests: Visually Exploring Random Forests to CRAN at (http://cran.r-project.org/package=ggRandomForests)

The biggest news is the inclusion of some holiday reading – a ggRandomForests package vignette!
ggRandomForests: Visually Exploring a Random Forest for Regression

The vignette is a tutorial for using the ggRandomForests package with the randomForestSRC package for building and post-processing a regression random forest. In this tutorial, we explore a random forest model for the Boston Housing Data, available in the MASS package. We grow a random forest for regression and demonstrate how ggRandomForests can be used to when determining variable associations, interactions and how the response depends on predictive variables within the model.

The tutorial demonstrates the design and usage of many of ggRandomForests functions and features. We also demonstrate how to modify and customize the resulting ggplot2 graphic objects along the way.

Next up in the package development queue is the completion of the Survival in Random Forests vignette (Preliminary draft version is avialable on CRAN also). A time to event analysis of the primary biliary cirrhosis (PBC) of the liver data from Fleming and Harrington (1991) “Counting processes and survival analysis.”

The development version of ggRandomForests is on GitHub at (https://github.com/ehrlinger/ggRandomForests)

Please comment on the article here: Learning Slowly

The post Christmas release: ggRandomForests V1.1.2 appeared first on All About Statistics.

I love bicycling. While I could write a whole manifesto about why bike riding is badass, today I'll focus on one key aspect: my commute. I get from home (Prospect Heights) to work (Soho) in 20-22 minutes, depending on how good I feel. Compare that with 30 minutes of subway + walking (when the B or Q is running that is). Bike wins every time.

Commuting in the Winter months is particularly pleasant, because there aren't many other riders - or, God forbid, pedestrians walking on the bike only North side - clogging up the Manhattan bridge. I notice however that as the temperature dips below 35 degrees or the clouds begin to gather, my friends and coworkers become more reluctant to take their bikes out. This leads to me wonder: am I that much more dedicated (aka hardcore)? Could it really be??

I did what any reasonable person would do - I looked to the data.

I pulled daily ridership data from the first two years of the Washington DC Bike Share program (2011-2012). It shows the daily number of bicyclists using the Bike Share and how that number fluctuates according to various environmental and seasonal factors. These factors include weather condition, temperature, humidity, windspeed, weekday, holiday, etc... Two rider types of interest for us are the "registered" (monthly/annual contract) and "casual" (1-5 day pass) riders.

Though I ride my own bike (but still fully support Citi Bike - just wear a damn helmet!), I bet that my bike habits are more similar to a registered rider than a casual one.

Digression: I should note that I am a very casual person, and in the ride of life, am more likely to be considered a casual than registered rider.

Right off the bat you might think that temperature is a huge differentiator between registered and casual riders. And it is...kinda...

This chart shows the proportion of registered and casual riders at different temperatures. It's clear that registered folks are more likely to be riding at colder temperatures. 

The only kink? Out of 2 years of daily temperature data, only 133 days had temperatures under 30 degrees. Not insignificant, but not enough to make it into the model, especially in light of correlations with other weather-related variables.

What other weather-related variables you ask? What about the Season...

Notice how the curves are moving to the right as the Season gets colder. 

The above chart says that in the Summer months, the difference between the number of registered and casual riders on a given day is small (check out the x-axis). Conversely, in the colder months, the difference is large - there are more days with large differences. This makes enough of an impact to keep in the model.

Continuing in this manner, it turns out that the strongest indicators* of the difference in the number of registered vs. casual riders on a given day are:

1. Season
2. Work Day (i.e. non-holiday or weekend)
3. Weather (Rain, Sun, Cloud, Snow)
4. Year of the Bike share program

That is, registered riders are more likely to ride than casual riders in the Winter, on a working day, in worse weather, and in the second year of the program (compared to the first).

Now comes the time for introspection - could I be a registered rider? 

• Compared to the casual riders I know, I bike more in the Winter months than the Summer months.
• Save for the Summer months when I might be doing long weekend rides, commuting to work takes up a majority of my miles (and harrowing mornings).
• Other than in icy conditions, I'll be on my bike all year - rain or shine or icy conditions.
• Bikes and Bike Shares rock, but sometimes it takes people a while to get there, especially in metropolitan areas. It wasn't until my second year living in New York that I got my bike. One of the best decisions I've ever made.

Hurray, my journey is complete. It appears I could be considered a registered rider!

The question remains: are you hardcore?

*Adjusted R^2 = 80%
**Click here for code!

Please comment on the article here: The Data Game - Ilan Man

The post Are you hardcore? appeared first on All About Statistics.

Release early and often.
http://cran.r-project.orgggRandomForests/index.html

I may have been aggressive numbering the first CRAN release at v1.0, but there’s no going back now. The design of the feature set is complete even if the code has some catching up to do.

After the v1.1.0 release we found a bug in gg_partial when handling plots for categorical variables. I’ve also moved the eventtable function to gg_survival. gg_survival will now be used for all Kaplan-Meier and Nelson-Aalen estimates. I still need to extend it for curves other than survival, but it’s a start.

I’ve also made more progress on the vignette, which is driving the TODO list pretty hard. I’m knocking things off as I need them, so it goes both ways.

Please comment on the article here: Learning Slowly

The post ggRandomForests: Visually Exploring random forests. V1.1.1 release. appeared first on All About Statistics.

If a picture is worth a thousand words, then how many tables are a single visualization worth? Exploratory data analysis is a great way to see what is and is not in your dataset.

I work in a hospital research group. Most of my colleagues are more comfortable in SAS than in R. One of the first ideas I had to help the workflow here was to create an R script that generated a series of data plots to visualize variables within our analysis dataset. This allowed our statistical programmers to do some data checking for quality, outliers and missing data before handing the data set to our biostatisticians. This moved the error checking step up in the project workflow, hopefully saving some time and making us all more productive.

The problem was this script required some custom edits for every data set. Something that the stat programmers wanted to learn, but in the heat of (deadlines) battle, that time for learning new things rarely happens. Hence it gets put off until “later”.

I’ve been contemplating how to use Shiny apps for a long time, and this finally caused me jumped in. It was pretty simple to get started actually, I just dumped a bunch of code I had been using (read: copy and pasting into lots of jobs) and put it in the server.R file. I created a ui.R and BAM! the xportEDA Shiny app was born!

xportEDA A shiny app for data visualization

xportEDA is a Shiny app that generates graphics used to explore your data set. It started out for SAS xport files only, but we’ve added csv and some rdata file support. Written in [R](http://cran.r-project.org/), this shiny app requires the following packages:

• shiny
• foreign (to load SAS xport files)
• ggplot2 (nice figures)
• reshape2
• RColorBrewer (color palettes are my friend)

Description

The xportEDA app makes it easy to visualize your data quickly, without requiring programming effort to get a jump on your data wrangling.

You supply the app with a data file. The app can read in a data.frame from a SAS xpt, csv or rdata file, and generates a set of data visualizations.

The app first classifies the variables as continuous, logical or categorical. Any variable with only 2 unique values is interpreted as logical. An ad-hoc definition for categorical variables is any factor plus any variable with more than 2 and less than 10 unique values. By default, character variables are converted to factors, however if we have more than 20 levels, we will not show a panel figure for that variable.

The app creates a faceted set of histograms for all categorical and logical variables, and another set of scatter plots for all continuous variables. Since we often are working in time-to-event settings, the app searches the variable names for some of our “standard” time related variable names to use for the x-axis. Typically, we use a “date of procedure” for this. However, if your data does not have a “time” variable name, we will select the first continuous variable for the x-axis. This variable can be changed though the Shiny interface.

A separate page is set up for visualizing individual variables, making it easy to export a single figure for use in reports or other communications. Useful for when your collaborators do not believe you are missing large chunks of data in a variable, or there are negative values for strictly positive variables, like height.

We also include a data summary page for further data debugging purposes.

Examples

This example is from our research data.

The bottom panel also shows a simple way to check goodness of follow up for time to event data. We expect the triangular shape as subjects that entered the study early should have the longest follow up. The internal part of the triangle should be mostly red xs, indicating an event occurred (death) and most of the blue circles should be on the hypotenuse of the triangle, as they indicate censored or alive case, occuring hopefully at the end of the study as opposed to lost to follow up cases in the interior.

Running the App

To try it out, you can see it on the shinapps.io site
https://ehrlinger.shinyapps.io/xportEDA/

I have also posted the app code to a GitHub repository where you can download it, and try it out. Let me know how it goes, report bugs or contribute back. I’d love to make this better, and learn more Shiny tricks along the way.

The easiest way is to run the app locally is to download it from the https://github.com/ehrlinger/xportEDA repository.

Then run it from R
R> library(shiny)
R> runApp()

or run it in R directly from the repository:

R> shiny::runGitHub("ehrlinger/xportEDA")

Issues and Caveats

I could put the standard “use at your own risk” disclaimer here. I will also add:

The app is written with my specific problem domain in mind though I am open for suggestions on how to improve it.

We tend to use time to event data (working in a hospital after all).

Our group uses SAS predominantly, hence the “xport” functionality and the app naming structure.

xportEDA will have trouble with large p data sets, as I have not figured out how to make shiny extend the figures indefinitely down the page. I do dynamically set the number of columns in an effort to control how small the panel plots get. But if you get into the 75 categorical or continuous variable range, it may become illegible.

Progress not perfection! The best way to start, is to start.

Please comment on the article here: Learning Slowly

The post Look! It’s your data! appeared first on All About Statistics.