Decoder rounding about mlj.jl HOT 7 CLOSED

The decoder expects the same input type for inverse_transform as output by transform. Any other behaviour would be confusing, it seems to me. I am not familiar with the package to know what float predictions are supposed to mean.

from mlj.jl.

So what would you suggest in this case? that the work around I proposed is ok for now and will be applied for any model that outputs floats instead of classes?

As far as I'm aware there are other algorithms that convert the class number into a continuous float and try to predict that (e.g. Poisson regression model IIRC).

I understand it may not be a good idea to do this rouding/clamping inside the inverse_transform though. But it might be worth investigating to see what sklearn or similar does.

from mlj.jl.

Is your GP algorithm modelling a nominal target or an ordered categorical? See also this new issue.

from mlj.jl.

I need to understand their code in more depth, see also the issue I opened STOR-i/GaussianProcesses.jl#108.

The problem is that their doc is severely lacking so it's kind of hard to get in the nitty gritty without just reading the whole code.

I do believe that what I've coded is effectively a count regression and therefore produces ordered categorical instead of classes. Once they get back to me I'll come back here and adjust correspondingly.

from mlj.jl.

short comment which is potentially helpful (or not): I don't see any in-principle reason for that the decoder (aka inverse transform) should be mathematically the exact inverse of the encoder, so why not allow the user to put out-of-bound fixes etc in the decoder?

from mlj.jl.

This implementation has a some flaws and I disabled it. Roughly, the problem is the a GP Regressor is being used to carry out GP Classification.

from mlj.jl.

This discussion seems a little stale now. Feel free to re-open or just continue discussion

from mlj.jl.