use predict instead of transform

[gdkrmr]

why is MultivariateStats using transform and not predict as the rest of the stats-ecosystem in Julia?

[wildart]

I'm not sure, but @lindahua definitely knows why. After some digging, this can be relevant: JuliaStats/Roadmap.jl#4 (comment)

My understanding that transform is used in a dimensionality reduction context, predict in other cases.

[nalimilan]

This package is very old, so it could make sense to rename some methods now that the ecosystem has evolved. If that's possible, using predict would be nice as it would avoid clashes with other packages (like data management packages).

[rofinn]

FWIW, I think transform makes more sense for dimensionality reduction, but it probably shouldn't be exported. Maybe StatsBase should define it and MultivariateStats could extend it?

[nalimilan]

I'd be fine with defining it but not exported. I guess it could be defined in StatsBase, but only if other stats packages use it.

It's the kind of situation where I wish there was a transform function in Base. Then packages could override it with their custom functions without any risk of ambiguity.

[gdkrmr]

The new AbstractDataTransform in StatsBase.jl define transform but do not export it. JuliaStats/StatsBase.jl@641236d

[wildart]

For some methods transform comes with an inverse operation, i.e. reconstruct. Not a perfect name but it gives a hit to an appropriate action (in scikit-learn, it's called inverse_transform). It would be hard to come up with a suitable inverse action name for a predict.

[gdkrmr]

transform -- reconstruct
predict -- reconstruct
I don't see the issue :-)

[ablaom]

Names are important. I struggled for some hours to make sense of the MLR documentation because I could not undersand what the trafo method was supposed to be. Once I realised that trafo meant transform, everything became infinitely clearer.

Personally, I find it helpful if the name is suggestive of function. A PCA projection will never be a "prediction" in my mind. Define a transform method and overload predict if you want to.

I do like the reconstruct suggestion, especially because the inverse_transform is sometimes only approximate (eg, discretization) or is only a one-sided inverse. I think we will switch to that in MLJ. :-)