implement statsapi

[tiemvanderdeure]

It could be neat if MLJ implemented StatsAPI as to avoid duplicate function names

julia> using MLJBase, GLM

julia> predict
WARNING: both GLM and MLJBase export "predict"; uses of it in module Main must be qualified
ERROR: UndefVarError: `predict` not defined

This could be avoided if MLJBase used StatsAPI.predict

[ablaom]

I agree it would be neat but I'm not sure it makes sense at the present time. Here are few reasons:

• I presume StatsAPI predict has a different contract for predict than MLJModelInterface.

• StatsAPI does not have a transform method at all, and it might be confusing to source one method from StatsAPI and not the other. StatsAPI also has no inverse_transform - they call it reconstruct. This is not a criticism of StatsAPI - I'm pointing out that the needs and emphasis are different. Frustratingly, DataFrames has it's own transform, which also conflicts with MLJ's transform, but DataFrames is too big a dependency to add to MLJModelInterface.jl.

• Changing method ownership is technically breaking. This has got me into trouble before, although I don't recall the reason.

I'm pretty sure MLJModelInterface predates StatsAPI. At the time we considered taking predict from StatsModels, which I think used to own the method, but didn't want the heavy dependency.

I've personally come around to believing the goal of reducing all method names to a single source is very ambitious, given the number of packages, different approaches, etc.

Perhaps we can revisit this question when there is little more stability.

Related project: LearnAPI.jl.

[ablaom]

Oh, and reversing our decision about ownership is definitely breaking.

[tiemvanderdeure]

Makes sense, thanks for taking the time to provide the reasons for this!