Element-wise multiplication

Open akroviakov opened this issue 4 years ago • 1 comments

Describe the bug Element-wise multiplication of SparseTensor is not consistent with documentation. Documentation states: If you add two sparse tensors, this will add two features. In case where there is a non-zero element, but not on the other sparse tensor at a specific coordinate, we assume 0 for the non-existing value since a sparse tensor saves non-zero elements only. Anything that we do not specify is 0 by definition. Same goes for all other binary operations.

To Reproduce Print the output of multiplication in sparse_tensor_arithmetics() function of sparse_tensor_basic.py:

  C = A * B 
  print(C)

Where A originates from:

data_batch_0 = [
    [0, 0, 2.1, 0, 0],  #
    [0, 1, 1.4, 3, 0],  #
    [0, 0, 4.0, 0, 0]
]

And B originates from:

data_batch_1 = [
    [1, 0, 0],  #
    [0, 2, 0],  #
    [0, 0, 3]
]

The output SparseTensor contains:

  coordinates=tensor([[0, 1, 3],
        [0, 1, 2],
        [0, 0, 2],
        [0, 2, 2],
        [0, 1, 1],
        [0, 0, 0]], dtype=torch.int32)
  features=tensor([[ 3.0000],
        [ 1.4000],
        [ 2.1000],
        [12.0000],
        [ 2.0000],
        [ 0.0000]])

Expected behavior As per documentation, it is expected that values at coordinates of A, that are non-existent in B will be multiplied by 0, thus it is expected that coordinate [0, 1, 3], [0, 1, 2], [0, 0, 2] would contain 0, but they are left unchanged.

Desktop:

OS: Ubuntu 20.04
Python version: 3.8.5
Pytorch version: 1.9.0
CUDA version: 11.1
NVIDIA Driver version: 470.57
Minkowski Engine version 0.5.4

==========System==========
Linux-5.11.0-25-generic-x86_64-with-glibc2.17
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"
3.8.11 (default, Aug  3 2021, 15:09:35) 
[GCC 7.5.0]
==========Pytorch==========
1.9.0+cu102
torch.cuda.is_available(): False
==========NVIDIA-SMI==========
/usr/bin/nvidia-smi
Driver Version 470.57.02
CUDA Version 11.4
VBIOS Version 90.06.5C.00.12
Image Version G001.0000.02.04
GSP Firmware Version N/A
==========NVCC==========
/usr/local/cuda-11.1/bin/nvcc
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2020 NVIDIA Corporation
Built on Mon_Oct_12_20:09:46_PDT_2020
Cuda compilation tools, release 11.1, V11.1.105
Build cuda_11.1.TC455_06.29190527_0
==========CC==========
/usr/bin/c++
c++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

==========MinkowskiEngine==========
0.5.4
MinkowskiEngine compiled with CUDA Support: True
NVCC version MinkowskiEngine is compiled: 11010
CUDART version MinkowskiEngine is compiled: 11010

Additional context If element-wise operation is meant as e.g., "applied on every present feature of the left operand", then the documentation has to mention this kind of a behavior or at least provide the expected results of the examples. If this is indeed an unexpected behavior for element-wise multiplication, it would be nice to have it fixed.

P.S. There is already Union operation present, so Intersection would also be nice to have (e.g., for easy IoU).

Aug 13 '21 09:08 akroviakov

I duplicated this issue with a short code to reproduce it (#415 ).
Also if that can help you, to compute the intersection it is possible to use: (|x+y| - |x-y|)/2 .

Nov 01 '21 22:11 bricerauby