Deprecate compute_on_step

[SkafteNicki]

🚀 Feature

Deprecate compute_on_step argument in all modular metrics.

Motivation

Setting compute_on_step argument to False essentially turn forward into update, since this is the only code that is then being executed:
https://github.com/PyTorchLightning/metrics/blob/5b6cb1d0e735544e6c42cc39bbe7eb29561b75e1/torchmetrics/metric.py#L204-L205
It is sometimes a good thing to have multiple ways of doing certain operations, however in this case IMO it will be much more clear to the user that update always do not return anything and forward always returns something.

Pitch

The flag have been there since the beginning, but we as we are now starting the process of refactoring it is worth considering if it should still be part of the framework when it just adds a duplicate of a feature we already have.

Alternatives

Additional context

[Borda]

I do not have any very strong opinion, I feel we can deprecate it... 🐰
cc: @PyTorchLightning/core-metrics

[ananthsub]

@SkafteNicki - n00b question: why should forward call update vs the functional definition of the metric if available?

[SkafteNicki]

@ananthsub forward will still have a double purpose of both returning the metric on the current batch and adding to the global metric state. So this will be the recommend way to do things in TM:

• want the metric only on the current batch -> call functional
• want to only aggregate the metric for all batches -> call update and then compute
• want both metric on current batch + aggregation for all batches -> call forward and compute

[ananthsub]

@SkafteNicki would this be the pseudocode for forward in the future?

def forward(*args, **args):
    self.update(*args, **args)
    return fn(*args, **args)

[mmlynarik]

@ananthsub forward will still have a double purpose of both returning the metric on the current batch and adding to the global metric state. So this will be the recommend way to do things in TM:

* want the metric only on the current batch -> call functional

* want to only aggregate the metric for all batches -> call update and then compute

* want both metric on current batch + aggregation for all batches -> call forward and compute

Hi, can you please explain a little bit what is the difference between functional call and forward? I'm still not quite sure about all the details regarding metrics evaluation, e.g. I thought that self.train_acc(preds, y) is equal to self.train_acc.forward(preds, y) Thanks a lot!

[ragavvenkatesan]

+1 to this comment. Seems like,

• forward updates the state and returns the current input's metric.
• compute computes the metric from current state.
• update only updates the current state.

Is this right?
Thanks.

[SkafteNicki]

update only updates the current state.

Yes, that is completely right :]