Revolutions

Registration now open for useR! 2014 in LA

Join hundreds of other R users from around the world at the annual worldwide R user conference useR! 2014, to be held June 30 - July 3 at the UCLA campus in Los Angeles.

Registration is now open for attendees. Advance registration for the conference is just $375 — and even less for academics ($250) and students ($125). Register by May 10 to get the best rates.

If you need a place to stay in LA, campus housing at UCLA is a great option. Single serviced rooms, including air-conditioning, cable TV and WiFi are available for $134 for a night (even less if you share a double). If a hotel is more your style, there are several in the vicinity.

Revolution Analytics is proud to be a major sponsor of useR! 2014. For more information about the conference, follow the link below.

useR! 2014: Registration

Predict which shoppers will become repeat buyers

by James P. Peruvankal

Kaggle just announced a competition to predict which shoppers will become repeat buyers. To aid with algorithmic development, they have provided complete, basket-level, pre-offer shopping history for a large set of shoppers who were targeted for an acquisition campaign. Files containing the incentives offered to each shopper as well as their post-incentive behavior are also provided.

This challenge provides almost 350 million rows of completely anonymised transactional data from over 300,000 shoppers. It is one of the largest problems run on Kaggle to date. Once unzipped, data size will be 22GB, more than what can fit into the memory of usual laptops.

If you like this sort of thing, a first look at the data ought to captivate your interest. The following plots shows the number of repeated trips to the store plotted against the offer value in dollars on the x axis. The data are shaded by market, a geographical area.

To get your own first look at the data, and maybe try out a few of the fast Parallel External Memory Algorithms included in Revolution R Enterprise, you might find it helpful to take advantage of Revolution Analytics offer to try out Revolution R Enterprise in the AWS cloud. (If you spin up a Linux box in AWS, you can go up to 64GB RAM.)

This contest is representative of the challenge coping with the exponential growth in real-world data projects. I am sure, we will see more of these kind of problems.

In addition to trying Revolution R Enterprise in the cloud, active Kaggle competitors can download the full-featured Revolution R Enterprise software and use it for free to create their own submissions.

Some of us Revolutionaries are jumping into the fray. See you at the competition!

A world map of R user activity

R easily has more than two million users around the world, but where is R activity the most concentrated? That's the question that the team of R users at Rapporter seeks to answer, by combining data about locations of R Foundation members, package authors, package downloaders, and user group members into a single, country-wide "R usage score". Those R user scores are then adjusted for population and presented on the map below: red represents the least R activity, and blue the most. (Click the map to go to the interactive version on the Rapporter website.)

On a per-capita basis, the country with the most R activity is not what you might expect: New Zealand, the birthplace of R, ranks #2. Here are the top 10 countries:

1. Switzerland
2. New Zealand (birthplace of R)
3. Austria (home of the R Foundation)
4. Ireland
5. United States Minor Outlying Islands*
6. United States
7. Australia
8. Singapore
9. Denmark
10. United Kingdom
11. Canada

From the source data it looks like "United States Minor Outlying Islands" is, well, an outlier with population 316 but as much CRAN usage as the entire USA, and so it should probably be excluded from the list. So welcome to the top 10, Canada! Check out the interactive map at the link below, and you can read a little about the data collection methodology (with R code) in this blog post.

Rapporter: R activity around the world

Because it's Friday: Two ways to see sound

What would it be like if you could actally see the sounds around you, with your eyes? Surprisingly, it's possible to do so, thanks to a couple of fairly simple techniques. One way is via Schlieren Photography, which makes the variations in air density caused by temperature and sound waves to become visible. How that's done is explained in the NPR video below (watch for the Millennium Falcon!).

 

Another way is to use a Ruben's tube. Gas flowing through a small hole flows faster or slower along a standing wave, which creates a visible pattern when the gas is lit on fire. The always-excellent Derek Muller of Veritasium meets a Danish physics teacher who's created a 2-D fire plate that dances to the music played through the speakers in the gas chamber, to create a device that's sure to feature in a nightclub with lenient safety codes somewhere soon:

 

That's all for this week. Enjoy your weekend, and we'll see you back here on Monday!

NYT uses R to forecast Senate elections

Nate Silver's departure to relaunch FiveThirtyEight.com left a bit of a hole at the New York Times, which The Upshot — the new data journalism practice at the Times — seeks to fill. And they've gotten off to a great start with the new Senate forecasting model, called Leo. Leo was created by Amanda Cox (longtime graphics editor at the NYT) and Josh Katz (creator of the Dialect Quiz), and uses a similar poll-aggregation methodology to that used by Silver. The model itself is implemented in the R language, and the R code is available for inspection at GitHub.

As of this writing, Leo suggests that the Democrats have a 51% chance of retaining the Senate in the 2014 elections. Now, probabilities are subtle things, and some commentators are prone to report from an estimate like this that "Leo predicts the Democrats will win the Senate in 2014". Of course, that would still be a risky bet to make, "essentially the same as a coin flip" as the Leo website says. As long as the probability isn't 0% or 100%, the actual outcome is always in doubt, dependent on factors we can't measure and over which we have no control. (In other words, luck.) The Upshot does a lovely job of demonstrating this variability with a feature that spins roulette wheels, loaded according to the data (mainly polls) for each race, and simulates one possible outcome.

This is a fantastic way to demonstrate the inherent variability in any statistical forecast, and it ties in with the underlying methodology as well. (For the statisticians out there, those wheels don't spin independently; correlations between individual races are taken into account.) Spin those wheels hundreds or thousands of times, count the number of times Democrats or Republicans win, and you have an estimate of the overall probability each party wins. Nicely done!

The UpShot: Senate Forecasts (via Sharon Machlis)

R Helps With Employee Churn

by Joseph Rickert

Pasha Roberts, Chief Scientist at Talent Analytics, is writing a series of articles on Employee Churn for the Predictive Analytics Times that comprise a really instructive and valuable example of using R to do some basic predictive modeling. So far, Pasha has published Employee Churn 201 in which he makes a case for the importance of modeling employee churn, and Employee Churn 202 where he builds a fairly sophisticated interactive model from first principles using only RStudio and basic R functions. And, while the series is not even complete, I think that is is going to be unique because it is working well on multiple levels.

In Churn 201, Pasha uses R almost incidentally, to produce the following plot that illustrates the concepts involved in understanding the costs and benefits contributed by a single employee. 

 

At the lowest level, this is a nice example of what might be called a “programming literate essay”. R clearly isn’t necessary just to build create a graphic. (Note the use of ggplot's annotate() capability.) But, if you look at the R code behind the scenes, you will see that Pasha has gone a bit further. In a few lines of annotated code he has sketched out a self-documenting model that someone else could use to get “back of the envelope” results for their business. The exercise is roughly at the level of what a business analyst might attempt in an Excel spreadsheet.

In Employee Churn 202, Pasha goes still further moving the series from essays alone to a modeling effort. He uses basic survival analysis ideas and simple R functions to create a sophisticated decision model that computes several performance measures including something he calls Expected Cumulative Net Benefit. This measures the net benefit to the corporation employees who leave for both “good” and “bad” reasons.

The following figure shows the simulation running in RStudio complete with interactive tools built with the manipulate() function to perform "what if" analyses and display the results.

Running the simulation is easy. All of the code is available on Github where the file, churn202.md, provides details on how things work. Once you have run the code in the churn202.R or issued the command source("churn202.R") from the console, running the function manipSim202() will produce the simulation. (Note that might be necessary to click on “gear” icon in the upper left hand corner of the plots panel to have the slide bar controls appear.) The function runSensitivityTests()varies each of the parameters in the simulation through a reasonable range of values, while holding the other parameters fixed, to show the sensitivity of Expected Net Chumulative Benefit to each parameter. The function runHistograms() produces histograms of the synthetic data that drive the simulation and hints at the data collection effort that would be required to run the simulation for real.

By placing the code on GitHub and inviting feedback, comments and pull requests Pasha has raised his literary efforts to the status of an open source, employee churn project without comprimising the clarity of his exposition. I, for one, am looking forward to the rest of thes series.

... and, we're back!

Sorry about the blog being inaccessible for a few days. Our hosting provider TypePad was the victim of a denial of service attack. (The Revolution Analytics main website and systems weren't affected.) But everything seems to be back to normal now, so it should be business as usual from here on in. We did keep publishing during the outage, so you might want to check back through the archives to see the posts you may have missed.

Benchmarking RRE and SAS

by Thomas Dinsmore

Regular readers of this blog may be familiar with our ongoing effort to benchmark Revolution R Enterprise (RRE) across a range of use cases and on different platforms.  We take these benchmarks seriously at Revolution Analytics, and constantly seek to improve the performance of our software. 

Previously, we shared results from a performance test conducted by Allstate.   In that test, RRE ran a GLM analysis in five minutes; SAS took five hours to complete the same task.  A reader objected that the test was unfair because SAS ran on a single machine, while RRE ran on a five node cluster.  It's a fair point, except that given the software in question (PROC GLM in SAS/STAT) the performance would be the same on five nodes or a million nodes, since PROC GLM can scale up but not out.

Arguing that the Allstate benchmark was "apples to oranges", SAS responded by publishing its own apples to orange benchmark.  In this benchmark, SAS demonstrated that its new HPGENSELECT procedure is very fast when it runs on a 144 node grid with 2,304 cores.  As noted in the paper, this performance is only possible if you license more software, since HPGENSELECT can only run in Distributed mode if the customer licenses SAS High Performance Statistics.

We will be happy to stipulate that PROC HPGENSELECT runs faster on 2,304 cores than RRE on 20 cores.

As a matter of best practices, software benchmarks should run in comparable hardware environments, so that we can attribute performance differences to the software alone and not to differences in available computing resources.   Consequently, we engaged an outside vendor with experience running SAS in clustered environments to perform an "apples to apples" benchmark of RRE vs. SAS.  The consultant used a clustered computing environment consisting of five four-core commodity servers (with 16G RAM each) running CentOS, Ethernet connections and a separate NFS Server.

We tested RRE 7 versus SAS Release 9.4, with Base SAS, SAS/STAT and SAS Grid Manager.  (We did not test with SAS High Performance Statistics because we could find no vendors with experience using this new software.  We note that more than two years into General Availability, SAS appears to have no public reference customers for this software.)  In our experience, when customers ask how we perform compared to SAS, they are most interested in how we compare with the SAS software they already use.

To test Revolution R Enterprise ScaleR, we first deployed IBM Platform LSF and Platform MPI Release 9 on the grid, then installed Revolution R Enterprise Release 7 on each node.  SAS Grid Manager uses an OEM version of IBM Platform LSF that cannot run concurrently with the standard version from IBM, so we configured the environment and ran the tests sequentially.  

To simplify test replication across different environments, we used data manufactured through a random process.  The time needed to manufacture the data is not included in the benchmark results.  Prior to running the actual tests, we loaded the randomized data into each software product’s native file system: for SAS, a SAS Data Set; for Revolution R Enterprise, an XDF file.

Although we have benchmarked Revolution R Enterprise on data sets as large as a billion rows, typical data sets used by even the largest enterprises tend to be much smaller.  We chose to perform the tests on wide files of 591 columns and row counts ranging from 100,000 to 5,000,000, file sizes that represent what we consider to be typical for many analysts.  We also ran scoring tests on “narrow” files of 21 columns with row counts ranging up to 50,000,000.

Rather than comparing performance on a single task, we prepared a list of multiple tasks, then wrote programs in SAS and RRE to implement the test.  Readers will find the benchmarking scripts here, on Git together with a script to produce the manufactured data.

To implement a fair test, we asked the SAS consultant to review the SAS programs and enable them for best performance in the clustered computing environment.

Detailed results of the benchmark test are shown here, in our published white paper

• RRE ran the tasks forty-two times faster than SAS on the larger data set
• RRE outperformed SAS on every task
• The RRE performance advantage ranged from 10X to 300X
• The RRE advantage increased when we tested on larger data sets
• SAS’ new HP PROC, where available, only marginally improved SAS performance

We invite readers to use the scripts in your own environment; let us know the results you achieve.

Revolution Analytics Whitepapers: Revolution R Enterprise: Faster Than SAS 

Simpson's Paradox in a nutshell

Norm Matloff points us to a pithy example that sums up Simpson's Paradox perfectly, captured in the title of a medical paper: "Good for Women, Good for Men, Bad for People". He explains how Simpson's Paradox isn't a paradox at all, but just the consequence of including a minor variable in a model ahead of a more significant variable, and illustrates this with an R analysis of the UCB admissions data. You can also see an interactive analysis of the same data here.

Webinar: Big-Data Trees for R

If you missed last week's webinar presented by Revolution Analytics' US Chief Scientist Mario Inchiosa, Decision Trees built in Hadoop plus more Big Data Analytics with Revolution R Enterprise, the slides and webinar replay are now available for download. The webinar includes a demo of building decision trees and regression trees in Revolution R Enterprise, and using the Tree Viewer to inspect the resulting tree, starting at the 30:20 mark.

 

If you'd like to learn more about the big-data tree models in Revolution R Enterprise, check out the white paper, Big Data Decision Trees with R. You can also find the slides from Mario's webinar at the link below.

Revolution Analytics Webinars: Decision Trees built in Hadoop plus more Big Data Analytics with Revolution R Enterprise