Add transformer defined by R-style formula

[ablaom]

I think it would be useful (especially to R users) to have an MLJ formula-based transformer that can be inserted anywhere in an MLJ pipeline (or other composite model). Here "formula" means "one-side formula"; I don't think two-sided formulas make much sense in the MLJ context because the target and features are treated separately, like in sklearn.

StatsModels.@formula apparatus appears to provide most of what is needed here already - check out the docs. So this is hopefully just wrapping that.

This transformer would probably be a Static model with a one-sided StatsModels formula as parameter. Ideally, and for consistency, it would perform a table-to-table transformation, rather than a table-to-matrix transformation, which is what StatsModels does. This does cause problems for very-high cardinality categorical features (which get one-hot encoded when you apply StatsBase formula??) but does have the advantage that new columns would come with informative names for interpretation downstream of the transformer. Actually, it probably makes sense not to force one-hot encoding anyway, as not all supervised models need this and we already have transformers to do one-hot encoding which generate the new column names.

I recall slack discussions with @kleinschmidt about this (now lost to the ether). Perhaps he would care to chime in.

See also #314 and JuliaAI/MLJGLMInterface.jl#13

[ablaom]

@vollmersj

[ablaom]

Maybe some minor work involved in translating between the ScientificTypes.jl convention used in MLJ and the one specific to StatsModels.jl. Happy to provided guidance around this.

[kleinschmidt]

Yup, I think the main bits of work are integrating scientific types, resolving the one-sided/two-sided thing, and supporting table-table integration. The last bit might actually be pretty simple, you can do something like

modeltable(t::AbstractTerm, data) = NamedTuple([name => col for (name, col) in zip(coefnames(t), eachcol(modelcols(t, data)))]...)

[kleinschmidt]

For ScientificTypes support you'd probably want to override schema/concrete_term methods to generate the appropriate term types (which are probably going to be different than the two that StatsModels defines, which are ContinuousTerm and CategoricalTerm).

[ablaom]

@rikhuijzer

[vollmersj]

It should be fairly straight forward to implement this using statsmodels.jl