CPO: Composable Preprocessing Operators

[mb706]

This is my GSoC project. See the preliminary vignette for a quick overview (more compact version with the R output removed).

Description for a General Audience

@everyone. If you have questions, ideas or feedback, please don't hesitate to write me, here or in other places!

What is this?

Functions for data manipulation and pre-processing ➕ a replacement for makePreprocWrapper ➕ lots of syntactic sugar.

Description

CPOs are called like functions and create an object that has Hyperparameters that can be manipulated using getHyperPars, setHyperPars etc.

> cpoPca()
pca(center = TRUE, scale = TRUE)
> cpoPca(scale = FALSE)
pca(center = TRUE, scale = FALSE)
> cpo = cpoPca(scale = FALSE)
> getHyperPars(cpo)
$center
[1] TRUE

$scale
[1] FALSE

> setHyperPars(cpo, center = FALSE)
pca(center = FALSE, scale = FALSE)

These objects can be applied to Tasks or data.frames to manipulate data, or can be attached to a Learner to create a wrapped learner similar to makePreprocWrapper.

> # PCA-rotate pid.task
> rotated.pid.task = pid.task %>>% cpoPca()
>
> # rotate a data.frame
> rotated.attitude = attitude %>>% cpoPca()
> # use the same rotation matrix on a
> # shorter version of the DF
> short.rotated.attitude = head(attitude) %>>% retrafo(rotated.attitude)
> all.equal(head(rotated.attitude), short.rotated.attitude,
+   check.attributes = FALSE)
[1] TRUE
> 
> # Centering / Scaling *after* PCA
> neoPCA = cpoPca(center = FALSE, scale = FALSE, id = "pca") %>>% cpoScale()
> neoPCA
(pca.pca >> scale)(pca.center = FALSE, pca.scale = FALSE, center = TRUE, scale = TRUE)
>
> # Attach the above to learner
> pcaLogreg = neoPCA %>>% makeLearner("classif.logreg")
> getHyperPars(pcaLogreg)
$model
[1] FALSE

$pca.center
[1] FALSE

$pca.scale
[1] FALSE

$center
[1] TRUE

$scale
[1] TRUE

Custom CPO constructors can be created using makeCPOObject or makeCPOFunctional. Note it is possible to write the (re)transformation operations with curly braces, with the function header getting added automatically.

> # bogus example, multiply first column
> cpomultiplier = makeCPOFunctional("multiplierF", factor = 1: numeric[~., ~.],
+   cpo.trafo = {  # implicit 'function(data, target, factor = 1)' here
+     data[[1]] = data[[1]] * factor
+     attr(data, "retrafo") = function(data) {
+       data[[1]] = data[[1]] / factor
+       data
+     }
+     data
+   })
> head(getTaskData(pid.task %>>% cpomultiplier(10000)))  # note first column
  pregnant glucose pressure triceps insulin mass pedigree age diabetes
1    60000     148       72      35       0 33.6    0.627  50      pos
2    10000      85       66      29       0 26.6    0.351  31      neg
3    80000     183       64       0       0 23.3    0.672  32      pos
4    10000      89       66      23      94 28.1    0.167  21      neg
5        0     137       40      35     168 43.1    2.288  33      pos
6    50000     116       74       0       0 25.6    0.201  30      neg

Implementation details

@berndbischl, @mllg

"CPO" (the name)

Would you want me to use "TaskTransform" instead of CPO (or something entirely different)?

makeParamSet Syntactic Sugar

I wrote a function paramSetSugar that makes creating ParamSets much less painful. Example

> paramSetSugar(a: logical, b: integer[0, 10], c: numeric[, ]^2)
           Type len Def      Constr Req Tunable Trafo
a       logical   -   -           -   -    TRUE     -
b       integer   -   -     0 to 10   -    TRUE     -
c numericvector   2   - -Inf to Inf   -    TRUE     -

Do you like this idea in general (maybe you want to incorporate it into ParamHelpers?) or would you rather not like me to use this in my project?

Object based vs. Functional CPOs

I implemented both, one in R/CPOObjectBased.R, the other in R/CPOFunctional.R; the code shared by both is mostly in R/CPOAuxiliary.R. Both have some advantages and disadvantages. The object based could use less memory in theory, since it does not carry around an environment in its model that usually contains the training data. It is also easier to debug if you like to use debugonce. In turn, the functional implementation can be applied directly to Task objects (since the CPO objects are just functions in this case) and could probably quite easily be coerced into collaborating with the magrittr package.
Maybe have a look at the concrete implementations of mine to see which one you like more.

Note About Object Based Implementation

The makePreprocWrapper implementation in mlr relies on the transformation function returning an object list(data = [data], control = [control]). I had the idea of just having it return the resulting data, and using R magic to inspect the function's environment to get at the control. See e.g. the implementation of cpoScale:

cpoScale = makeCPOObject("scale", center = TRUE: logical, scale = TRUE: logical,
  cpo.trafo = {
    ## boilerplate :-( Hope to get rid of this at some point
    targetdata = data[target]
    data[target] = NULL
    ## here we go
    result = scale(as.matrix(data), center = center, scale = scale)
    data[] = result
    data[target] = targetdata
    ## the 'control' object will be retrieved by the CPO machinery
    ## and given to cpo.retrafo
    control = list(center = attr(result, "scaled:center"),
      scale = attr(result, "scaled:scale"))
    data
  }, cpo.retrafo = {
    ## here we have the 'control' object
    as.data.frame(scale(as.matrix(data),
      center = control$center, scale = control$scale))
  })

What is your opinion about this? Alternatives are: Copying the entire cpo.trafo namespace to cpo.retrafo, so the user wouldn't need to worry about which variables are available and which are not. The downside to this: This would take the entire training data and save it inside the model, might be memory intensive. I could also stop being fancy and just return the list(data, control) as in makePreprocWrapper. There is a way to inspect cpo.retrafo and copy only the objects that are used by it, but this inspection is bound to be incomplete (the problem is halting problem equivalent) and could copy more data than the retrafo part needs.

Composition operator

I choose %>>%, since it is similar, but not used by, magrittr. It applies to CPO in conjunction with Learners on the right and Tasks on the left, but does not do Task %>>% CPO %>>% Learner because of the associativity problem.

State of implementation

The current roadmap, as I see it; comments?

• makeParamSet syntactic sugar (R/ParamSetSugar.R)
• Object based CPO (R/CPOObjectBased.R)
• Functional CPO (R/CPOFunctional.R)
• CPO composition
• CPO attachment to Learner
• CPO application to Task / data.frame
• Easily do re-trafo on data after training on other data (i.e. perform the predict step without being attached to a Learner)
• Basic documentation (needs polish)
• Base functionality tests
• Small example CPOs (R/CPO_concrete.R)
• nicer API to avoid boilerplate code that is the same in most CPOs
• properties handling
• CPO multiplexer
• cpoCbind
• metaCPO
• list all built-in CPOs
• select features to affect / ignore
• Actually useful CPOs
• Testing concrete CPOs
• export / fix hyperparameters
• cpoCbind avoid copying redundant columns
• target CPO

Maybe some day...

• Task weights
• Task blocking

[lintr-bot]

R/measures.R:1435:73: style: Use FALSE instead of the symbol F.

​    perror = pec(probs, f, data = newdata[, tn], times = grid, exact = F, exactness = 99L,
                                                                       ~^

[larskotthoff]

What's the status here? Does this still need to merged for mlrCPO to work?

[mb706]

Yes please, mlrCPO relies on a few kinda-internal functions of mlr. Should be pretty stable as well (my last few commits were just running after merge conflicts).

[larskotthoff]

Thanks, merging.