Faster Accuracy metric

[Diuven]

What does this PR do?

Speeding up the Accuracy metric for classification tasks.

Fixes #2722

Before submitting

• Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
• Did you read the contributor guideline, Pull Request section?
• Did you make sure your PR does only one thing, instead of bundling different changes together? Otherwise, we ask you to create a separate PR for every change.
• Did you make sure to update the documentation with your changes?
• Did you write any new necessary tests?
• Did you verify new and existing tests pass locally with your changes?
• If you made a notable change (that affects users), did you update the CHANGELOG?

PR review

Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.

Did you have fun?

Make sure you had fun coding 🙃

[pep8speaks]

Hello @Diuven! Thanks for updating this PR.

• In the file tests/metrics/functional/test_classification.py:

Line 135:120: E501 line too long (127 > 119 characters)

Comment last updated at 2020-08-06 07:45:04 UTC

[justusschock]

@SkafteNicki @Borda @PyTorchLightning/core-contributors I think we now have to decide if we want to use the given num_classes or the calculated ones (especially if they don't match). Opinions?

[mergify]

This pull request is now in conflict... :(

[codecov]

Codecov Report

Merging #2775 into master will increase coverage by 1%.
The diff coverage is 98%.

@@           Coverage Diff           @@
##           master   #2775    +/-   ##
=======================================
+ Coverage      88%     90%    +1%     
=======================================
  Files          78      78            
  Lines        7069    7086    +17     
=======================================
+ Hits         6250    6371   +121     
+ Misses        819     715   -104     

[Diuven]

@SkafteNicki @Borda @PyTorchLightning/core-contributors I think we now have to decide if we want to use the given num_classes or the calculated ones (especially if they don't match). Opinions?

Actually, I updated the code to do the same thing with the previous code when it gets different num_classes from the real number of classes. So if you want to put off the decision or want to keep the behaviour, you can do so.

I think this behaviour (using the results only in the range specified by the num_classes) can be useful when the user want the stats of the certain classes.

But I do think that this is quite counter-intuitive, and removing it will make the function more clear and faster. We can just remove this behaviour for now and add it later on, with well designed structure.

This depends on the core developers' opinions, so I'm willing to update the PR correspondingly. Please share your thoughts! 😃

[Diuven]

I'm keep getting some pip install errors on CI test intermittently. Can someone check if some code of mine are causing such problems?

[justusschock]

@Diuven This keeps happening from time to time, although we don't know why. Usually retriggering helps (what I did now) :)

[justusschock]

LGTM, just the last missing docstring line :)