@jnothman is there any action expected on my side to merge this PR?

No, there is just a lot of competing demand on reviewers' time. Thanks for pinging

Hi @leonardbinet, thanks for your patience! Do you mind fixing conflicts? Hopefully, this will bring some attention again. Thanks!

@cmarmo here it is :)

Thanks @alk-lbinet . It seems to me that the failing check is unrelated to this PR. Perhaps @rth will find some time to review? Thanks!

We would also need an entry in what's new to announce that we support CSR matrices.

Bump, we currently accept sparse labels into autosklearn but we have to de-sparsify them to use type_of_target.

@leonardbinet would you be continuing this PR? If not, I am happy to try finish and push this feature through next week.

@leonardbinet can I get access to push this one, please?

Hi, @ilivans I gave you access, feel free to update my branch 👍

I think @GuoqiangOu 's questions come down to the next one:

• why type_of_target([[0, 0.5]]) == 'continuous-multioutput' and not 'continuous'?
  • it contradicts with the documentation indeed, as well as for 'multiclass-multioutput', however it has little to do with sparse matrices so it's outside of the PR's scope AFAIC, maybe it's worth creating an issue and fixing the documentation (or the behavior if necessary)

Another edge case that I found is

• type_of_target([[-1, 1]]) != type_of_target(csr_matrix([[-1, 1]])) ('multilable-indicator' != 'multiclass-multioutput')
  • seemingly the same matrix in different formats turns out to be of different types
  • this has to do with the assumption that sparse matrices have 0 as an implicit negative value, so the last matrix actually have 3 values (0, -1 and 1). I'm not sure it's worth documenting though, it seems to be common sense. I would actually make 0 the only acceptable negative value for multilabel.

In the last commits I addressed the comments regarding documentation, csc_matrix and explicit zeros.

It seems to be done to me. Please take a look, somebody 🙏

cc @glemaitre @rth

why type_of_target([[0, 0.5]]) == 'continuous-multioutput' and not 'continuous'?

It has two columns.

this has to do with the assumption that sparse matrices have 0 as an implicit negative value, so the last matrix actually have 3 values (0, -1 and 1). I'm not sure it's worth documenting though, it seems to be common sense. I would actually make 0 the only acceptable negative value for multilabel.

Is there sense in rejecting a full "sparse" matrix with no zeros and two nonzero values?

-1 has been a longstanding label for "negative" with thanks to support vector machines at least.

thanks @jnothman 🙌

why type_of_target([[0, 0.5]]) == 'continuous-multioutput' and not 'continuous'?

It has two columns.

It does, however the documentation (of the function) says

"'continuous-multioutput': y is a 2d array of floats that are
not all integers, and both dimensions are of size > 1."

If it was a (2,1) matrix (a column) it would be treated as 'continuous'.

this has to do with the assumption that sparse matrices have 0 as an implicit negative value, so the last matrix actually have 3 values (0, -1 and 1). I'm not sure it's worth documenting though, it seems to be common sense. I would actually make 0 the only acceptable negative value for multilabel.

Is there sense in rejecting a full "sparse" matrix with no zeros and two nonzero values?

-1 has been a longstanding label for "negative" with thanks to support vector machines at least.

It's a good question. I tried to give my opinion on this, I think it makes sense to reject such cases because of the underlying assumption of 0 being the "missing" value (there is a method csr_matrix.eliminate_zeros), so if you're using a sparse matrix as an indicator matrix, it should contain 1 unique value that's treated as positive. If you're using a sparse matrix with -1 and 1, you're misusing the format AFAIC.

It's easy to change the logic tho, so just lmk if you believe it's necessary to make it consistent with the dense case.

btw I can't change the PR description, but it also fixes #18611 now

Is there sense in rejecting a full "sparse" matrix with no zeros and two nonzero values?

I have to add, this logic hasn't been introduced by the PR, the PR just fixes exceptions, the logic was introduced in 2bfca14c4935eb524cfd7a65dec2370c1f03c857 (ENH sparse matrix support in label binarization):

    'multilabel-indicator': [
        ...
        csr_matrix(np.array([[0, 1]])),
        # Only valid when data is dense
        np.array([[-1, 1], [1, -1]]),
        np.array([[-3, 3], [3, -3]]),
    ],