[FEATURE] Missingness incorporated as attributes

[dwachsmuth]

I'm wondering if the package developers would be interested in building support for "missingness incorporated as attributes" (MIA) into the BART decision tree creation process. The idea is to avoid the need to either impute missing values or drop observations with missing values, and instead to let trees route missing data left or right as part of "normal" splitting rules, and also to split on the presence of missingness itself. This is a particularly useful approach when missingness actually encodes information that could be useful for predictions. (E.g. certain variables are suppressed in census tracts with low population, and that fact is correlated with the outcome variable.)

The technical details of MIA are described in this paper: https://arxiv.org/abs/1306.0618, and are currently implemented in the bartMachine R package. Here is the high-level summary of the splitting rules using MIA (copy-pasted from the paper):

1: If xij is present and xij ≤c, send this observation left (←−); otherwise, send this
observation right (−→). If xij is missing, send this observation left (←−).
2: If xij is present and xij ≤c, send this observation left (←−); otherwise, send this
observation right (−→). If xij is missing, send this observation right (−→).
3: If xij is missing, send this observation left (←−); if it is present, regardless of its value,
send this observation right (−→) .

This could be implemented via the existing API with an additional mia argument to the bart() and bcf() functions, which would presumably default to FALSE but when TRUE would implement MIA. bartMachine offers an additional use_missing_data_dummies_as_covars argument to control whether splitting can happen on missingness; this could also be exposed via the stochtree API.

I wish I had the technical skills to write up a PR, but hopefully this should serve as a decent overview of the idea.

[andrewherren]

Hi @dwachsmuth, thanks for opening this request!

I agree this would be a great thing to support, especially since it's already been worked out for BART and, as you mention, missingness is often highly informative.

The main challenge is that it requires some pretty substantial changes to the core of the codebase (i.e. the C++ representation of decision trees / split rules and routines for serializing / deserializing trees), so it's a nontrivial lift. Furthermore, I'd want to make sure that any changes to the core codebase don't impact performance of trees without MIA (i.e. if we make stochtree x% slower overall in order to support MIA, that wouldn't fly with most users).

What I can commit to now is thinking about the problem and writing up an RFC that scopes it out (see here for stochtree's RFCs). Whether / when we proceed will depend a bit on the scope of the work and our priorities.

If you don't mind, a reprex / simulated data example that elicits a performance difference between bartMachine with MIA and bartMachine without MIA would be super illustrative for me, so I can see how much worse stochtree is doing in some data contexts without this feature.