Handling non-float targets

[mihirparadkar]

As a followup to #86 , one difference between losses as implemented in LowRankModels and LossFunctions is that the targets in LowRankModels depend on the type (i.e. the default target type for LogisticLoss is Bool). This is very useful for fitting over DataFrames, for example, and keeping type-awareness. I think we should discuss some way to incorporate this here.

[mihirparadkar]

I think it'd be simple enough to implement methods where target is a Bool by mapping true to 1 and false to -1, which seems like it'd work for every loss except CrossentropyLoss (so every MarginLoss and DistLoss).

[joshday]

The pieces of what you're looking for may already exist in JuliaML. @Evizero has some very cool stuff in MLLabelUtils: http://mllabelutilsjl.readthedocs.io/en/latest/index.html

[mihirparadkar]

Interesting... Thanks for showing me this!
It seems like it also does some of the prediction work related to the bottom comments on #34

@madeleineudell , want to comment on this API for classification? It seems like a lot of the functionality of domains is captured by these label encodings (except maybe a couple of edge cases like predicting real-valued data using a MarginLoss)

[madeleineudell]

This is cool! Looks like it handles a bunch of our use cases, and could probably be extended to handle all of them.

[Evizero]

Note that its actually planned to support more flexibility in computing the loss, I just didn't get around to implement it yet.

The plan is to either piggy-back on MLLabelUtils LabelEnc

value(HingeLoss(), [true, true, false], [1.4, 0.2, -0.6], LabelEnc.TrueFalse())

or to incorporate something I have experimented at MLMetrics.

---

As a sidenote, we currently have some glue-code that does give special interpretation for sparse arrays where we simply assume that a 0 stands for the negative value https://github.com/JuliaML/LossFunctions.jl/blob/master/src/supervised/sparse.jl . Naturally this kind of convention is a bit hacky, but its a start

[juliohm]

This discussion is outdated by the latest developments in CategoricalArrays.jl Instead of supporting arbitrary encodings, I think what we really need is full support for categorical variables of any kind.