Why MultiLabelMarginLoss take torch.long has arguments?

1

Why MultiLabelMarginLoss take torch.long has arguments?

From understanding MultiLabelMarginLoss take not labels but one hot encoding labels so we can use multiclass multilabels prediction.
Why MultiLabelMarginLoss arguments shoud be long? It’s compose of only 0 and 1.

I have the following error if I try with uint8
RuntimeError: Expected object of scalar type Long but got scalar type Byte for argument #2 'target'

Is there something I miss?

2

Hi,

The target tensor is not expected to contain one hot encoding. from the doc:
"
The criterion only considers a contiguous block of non-negative targets that starts at the front.
This allows for different samples to have variable amounts of target classes
"
It should contain label values and be padded by -1s. For example if you have 3 labels and sample 0 is 0, 1 and sample 1 is 2 and sample 2 is 0,1,2:

label = [[0, 1, -1],
             [2, -1, -1],
             [0, 1, 2]]

This is a old design choice (the cpu code is >7years old and is part of the first commit on github, so it’s most certainly older than that), I’m not sure why this was made though.

2 Likes
3

Wow! I didn’t understand at all that :sweat_smile:
thank you so much!
Do you have any recommendation for multiclass multilabels classification?
I don’t know if there is better loss function or anything that can help :smile:

4

I think nn.BCELoss could be a good alternative. Here is a small example.

5

Also, is this notation has a name? for now in my code it’s the totoro encoding :sweat_smile:

6

Thank you for your exemple. is there any interest to use directly nn.BCELoss over nn.BCEWithLogitsLoss?

7

You can specify a pos_weight using nn.BCEWithLogitsLoss, but besides that, there is no difference apart from the additional sigmoid layer in nn.BCEWithLogitsLoss.

1 Like