Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding MultiLabel SoftMargin Loss #2345

Merged
merged 56 commits into from Aug 14, 2021

Conversation

iamshnoo
Copy link
Member

@iamshnoo iamshnoo commented Mar 31, 2020

In this PR, I am adding the Multi Label Soft Margin Loss function.
Here is a link to a Jupyter notebook to verify the outcomes presented in the test cases added.

@ojhalakshya
Copy link
Contributor

ojhalakshya commented Apr 1, 2020

Hi @iamshnoo
could you also add tests for this loss function in the

loss_functions_test.cpp

Thanks

@iamshnoo

This comment has been minimized.

@kartikdutt18
Copy link
Member

Hmm, That is strange.

@ojhalakshya
Copy link
Contributor

I have got an idea about this.
You can see a different type of tab placed just at the beginning of the line where you are getting ambiguity in different editors.
I think if you just remove that and add normal spaces/tab you will get same view in every editor.
image (1)

@ojhalakshya
Copy link
Contributor

You can zoom in to the pic to find the tab space I am talking about.

@kartikdutt18
Copy link
Member

Agreed and you set tab = 2 spaces (this is what mlpack uses).

@iamshnoo
Copy link
Member Author

iamshnoo commented Apr 1, 2020

Agreed and you set tab = 2 spaces (this is what mlpack uses).

Yep, that's what I had done initially before the review pointed out the misalignment. Then I tried changing it to 8 spaces and found the problem persisted in a different format.

I have got an idea about this.
You can see a different type of tab placed just at the beginning of the line where you are getting ambiguity in different editors.
I think if you just remove that and add normal spaces/tab you will get same view in every editor.

Yep, I am gonna try this out and see. Thanks for the suggestion.

@ojhalakshya
Copy link
Contributor

Happy to help!
Keep up the great work :)

@kartikdutt18
Copy link
Member

Hey there, This code touches the loss function portion of mlpack's codebase. Recently #2339 was merged where the switch was made to templated return type instead of just using double. So before we merge this, kindly make the changes for the same. I'm pasting this in all relevant PRs. Thanks a lot 👍

reduction(reduction),
weighted(false)
{
if (weights.n_elem)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be easier to understand what happens here, if we provide a second constructor to set the weights. Let me know what you think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi zoq, if you look at commit f298c7a, on May 5th, there I re-designed the API of this function to the current format after a long discussion above with @kartikdutt18. The conclusion of that discussion can be seen in this comment.

So, I think initially I had done what you are suggesting (let me know if you mean otherwise) using a overloaded constructor to set the weights. But then Kartik wanted me to design the API like this.

I am okay with both. Even though I would prefer the approach with an overloaded constructor

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I am guessing the other constructor would also have weights as param and probably a reduction also as param. It might ve redundant to have two constructors with same parameters. We would only have one forward function so we would have take into account both cases. For initialization we check if the vector is empty, if yes, we set reset to true and in forward pass we initialize the weights equal to input features and we set reset to false so we don't initialize every iteration. If weights are passed then we set reset to false and copy weights so no initialization in forward pass. Maybe I missed something, let me know what you think.
Regards.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In terms of API wouldn't an overloaded constructor be redundant. I am guessing one constructor will be with parameter reduction and one with both reduction and weights parameter. We can simply have one constructor and set weights to default value and in forward pass set them to 1 only in the first pass. This allows us to have a forward function which doesn't depend on which constructors object we are dealing with. I have left a comment explaining something similar.

const InputType& input, const TargetType& target)
{
if (!weighted)
classWeights.ones(1, input.n_cols);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could go into the other constructor, see comment above, that way we don't set this in each call of forward.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally agree! Detailed comment above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought I suggested using a reset parameter so this initialized only in the first pass. I am using my phone so sorry I can't take a look at the code. Similar thing is done in adaptive pooling layers. Regards.

Co-authored-by: Marcus Edel <marcus.edel@fu-berlin.de>
Comment on lines 42 to 43
if (!weighted)
classWeights.ones(1, input.n_cols);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, The weights will be initialised every time in forward pass here, You should set weighted to true here to prevent that from happening. As shown here, we use reset to prevent weights from being initialized every time i.e. If user has not passed weights they will be initialized once in forward pass.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed! This was something I missed completely. Corrected in the commit 77463d8.
Thanks to both zoq and you for pointing this out.

@mlpack-bot
Copy link

mlpack-bot bot commented Jul 1, 2020

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! 👍

@mlpack-bot mlpack-bot bot added the s: stale label Jul 1, 2020
@iamshnoo
Copy link
Member Author

iamshnoo commented Jul 1, 2020

Let's keep this open please!

@mlpack-bot mlpack-bot bot removed the s: stale label Jul 1, 2020
@mlpack-bot
Copy link

mlpack-bot bot commented Jul 31, 2020

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! 👍

@rcurtin
Copy link
Member

rcurtin commented Oct 10, 2020

Hey @iamshnoo, just wanted to check on this one---I see it's approved, but it seems like there is still work to do before it's ready for merge?

@iamshnoo
Copy link
Member Author

I will pull in the recent upstream changes to this branch in the next commit (hopefully in the next couple of days). Other than the merge conflicts and changing boost to catch2, there probably won't be too many other changes to make. Thanks for the reminder.

@jeffin143 jeffin143 force-pushed the multilabel_softmargin_loss branch 2 times, most recently from f36c858 to e7ef286 Compare February 21, 2021 18:41
@jeffin143
Copy link
Member

Hi @iamshnoo I solved the merge conflicts and also migrated test and also the serialisation part. If there is nothing left from your side we can go ahead with the merge

Since test failure are random

cc @zoq @rcurtin

@iamshnoo
Copy link
Member Author

Thank you for updating the PR! I feel it's ready from my end. Nothing more to add.

@zoq zoq added this to Need Review in PR Tracking Feb 23, 2021
@shrit shrit added this to the mlpack 4.0.0 milestone Apr 18, 2021
@jeffin143 jeffin143 merged commit 3f82130 into mlpack:master Aug 14, 2021
This was referenced Oct 14, 2022
@rcurtin rcurtin mentioned this pull request Oct 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
PR Tracking
Need Review
Development

Successfully merging this pull request may close these issues.

None yet