Add torch metrics support

[bagxi]

🐛 Bug Report

AdditiveValueMetric assumes that the metric value can be converted to float / NumPy array. But in reality, there are many cases when it is much faster and easier to calculate metrics on GPU using PyTorch. And this will cause errors as torch.Tensor cannot be converted to NumPy automatically.

How To Reproduce

Steps to reproduce the behavior:

1. Use FunctionalMetricCallback with any metric function that returns torch.Tensor e.g. piq.psnr

Code sample

https://github.com/leverxgroup/esrgan/blob/update-catalyst/esrgan/callbacks/metrics.py#L20

Expected behavior

It would be great if utils.detach_tensor was used before metrics averaging.

Environment

Please copy and paste the output from our environment collection script

catalyst-contrib --collect-env
# or manually
wget https://raw.githubusercontent.com/catalyst-team/catalyst/master/catalyst/contrib/scripts/collect_env.py
python collect_env.py

(or fill out the checklist below manually).

# example checklist, fill with your info
Catalyst version: 20.04.2
PyTorch version: 1.8.0
TensorFlow version: N/A
TensorBoard version: 2.2.1
OS: Ubuntu 20.04 LTS
Python version: 3.8
CUDA runtime version: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

Additional context

Checklist

• bug description
• steps to reproduce
• expected behavior
• environment
• code sample / screenshots

FAQ

Please review the FAQ before submitting an issue:

• I have read the documentation and FAQ
• I have reviewed the minimal examples section
• I have checked the changelog for main framework updates
• I have read the contribution guide
• I have joined Catalyst slack (#__questions channel) for issue discussion

[Scitator]

Nice catch!
Do you think adding mode=["numpy", "torch"] would be a good idea for AdditiveValueMetric?

[bagxi]

I think it will be easier to check types of inputs and use utils.detach_tensor in case of torch tensors?

[Scitator]

why you could not specify that during init?
checking dtype each batch looks like performance killer

[bagxi]

Sometimes people may have no ideas about types. And it also will be much easier to use this thing.

Can we assume that dtype of each batch is the same? If yes, then we can check dtype only for the first batch and store this information inside AdditiveValueMetric.

[Scitator]

the problem here is that it requires you to check the type each batch, which is some kind of slow
moreover... how could we do not know the dtype of the returned metric value? it should be documented, I hope

[bagxi]

And what about the function that will redefine itself on the first batch? In this case, dtype will be checked only once, but it is a little bit tricky approach.

[Scitator]

🤔 do you have an example of such a function?

[bagxi]

class Metric:
    # ...

    def update(self, value, ...):
        self.value = self.compute_wrapper(value)
        # ...

    def compute_wrapper(self, value):
        if torch.is_tensor(value):
            self.compute_wrapper = catalyst.utils.detach_tensor
        else:
            self.compute_wrapper = lambda x: x

    def compute(self):
        # ...
        return value

[Scitator]

why should we use such a metric with undefined behavior? do you have any real-metric examples?