title: "H2O World GLM Demo"

author: "Tomas Nykodym"

date: "November 7, 2015"

output: html_document

* Introduction

* Installation and Startup

* Cover Type Dataset

* Multinomial Model

* Binomial Model

* Adding extra features

* Multinomial Model Revisited

This tutorial shows how a H2O [GLM](http://en.wikipedia.org/wiki/Generalized_linear_model) model can be used to do binary and multi-class classification. This tutorial covers usage of H2O from R. A python version of this tutorial will be available as well in a separate document. This file is available in plain R, R markdown and regular markdown formats, and the plots are available as PDF files. All documents are available [on Github](https://github.com/h2oai/h2o-world-2015-training/raw/master/tutorials/glm/).

If run from plain R, execute R in the directory of this script. If run from RStudio, be sure to setwd() to the location of this script. h2o.init() starts H2O in R's current working directory. h2o.importFile() looks for files from the perspective of where H2O was started.

More examples and explanations can be found in our [H2O GLM booklet](http://h2o.ai/resources/) and on our [H2O Github Repository](http://github.com/h2oai/h2o-3/).

Load the H2O R package:

```{r load_library}

Start up a 1-node H2O server on your local machine, and allow it to use all CPU cores and up to 2GB of memory:

```{r start_h2o}

Predicting forest cover type from cartographic variables only (no remotely sensed data).

Let's import the dataset:

```{r import_data}

We got 11 numeric and two categorical features. Response is "Cover_Type" and has 7 classes.

Let's split the data into Train/Test/Validation with train having 70% and Test and Validation 15% each:

```{r split_data}

We got data in, let's run glm. As we mentioned previously, Cover_Type is the reponse and we use all other columns as predictors.

We have multi-class problem so we pick family=multinomial. L-BFGS solver tends to be faster on multinomial problems, so we pick L-BFGS for our first try.

The rest can remain default.

```{r build_model1}

The model predicts only the majority class so it's not use at all! Maybe we regularized it too much, let's try again without regularization:

```{r build_model2}

No overfitting(train and test performance are the same), regularization is not needed in this case.

This model is actually useful. It got 28% classification error, down from 51% obtained by predicting majority class only.

##Binomial Model

Multinomial models are difficult and time consuming, let's try simpler binary classification.

We'll take a subset of the data with only class_1 and class_2 (the two majority classes) and build a binomial model deciding between them.

```{r get_and_split_binomial_data}

We can run binomial model now:

```{r build_binomial_model_1}

The output for binomial problem is slightly different from the multinomial. The confusion matrix now has a threshold attached to it.

The model produces probability of class_1 and class_2 similarly to multinomial example earlier, however this time we only have two classes and we can tune the classification to our needs. The classification errors in binomial case have special meaning, we call them false-positive and false negative. In reality, each can have different cost associated with it and we want to tune our classifier accordingly. The common way to evaluate a binary classifier performance is to look at it's [ROC curve](https://en.wikipedia.org/wiki/Receiver_operating_characteristic). ROC curve plots true positive rate versus false positive rate. We can plot it from h2o model output:

```{r build_binomial_model_output_1}

The area under the ROC curve (AUC) is a common "goodness" metric for binary classifiers. We got:

```{r build_binomial_model_output_2}

The default confusion matrix is computed at thresholds which optimizes[F1 score](https://en.wikipedia.org/wiki/F1_score). We can choose different thresholds, h2o output shows optimal thresholds for some common metrics.

```{r build_binomial_model_output_3}

The model we just built gets 23% classification error at F1-optimizing threshold, there is still room for improvement.

Let's add some features:

* There are 11 numerical predictors in the dataset, we will cut them into intervals and add a categorical variable for each

* We can add interaction terms capturing interactions between catgorical variables

Let's make a convenience function to cut the column into intervals working on all three of our datasets (Train/Validation/Test).

We'll use h2o.hist to determine interval boundaries (many more ways to do that!) on the Train set.

We'll take only the bins with non-trivial support:

```{r cut_column}

Now lets make a convenience function generating interaction terms on all three of our datasets. We use h2o.interaction:

```{r generate_interactions}

Lastly, let's wrap adding of the features into seperate function call as we will use it again later.

We'll add intervals for each numeric column and we'll add interactions between each pair of binary columns.

```{r add_features}

Now we generate new features and add them to the dataset. We'll also need to generate column names gain as we added more columns:

```{r add_features_binomial}

Lets build the model, we should add some regularization this time because we added correlated variables, let's try default:

```{r build_binomial_ext_1}

Oops, does not run, we know have more features than the default method can solve with 2GB of RAM. Let's try L-BFGS instead.

```{r build_binomial_ext_2}

Not better, maybe too much regularization? Lets pick smaller lambda and try again.

```{r build_binomial_ext_3}

Way better, we got auc of .91 and classification error of 0.180838.

We picked our regularization strength arbitrarily. Also, we used only l2 penalty but we added lot of extra features, some of which may be useless.

Maybe we can do better with l1 penalty.

So we want to run lambda search to find optimal penalty strength and we want to have non-zero l1 penalty to get sparse solution.

We'll use IRLSM solver this time as it does much better with lambda search and l1 penalty.

Recall we were not able to use before. We can use it now as we are running with lambda search which will filter large portion of the inactive (coefficient==0) predictors.

```{r build_binomial_ext_4}

Better yet, we have 17% error and we used only 3000 out of 7000 features.

Ok, our new features improved binomial model significantly,let's revisit our former multinomial model and see if they make a difference there (they should!):

```{r build_multinomial_ext_4}

Improved considerably, 21% insetad of 28%.