GitLab

* Fixes for build with the new pytorch

* Fixes for build with the new pytorch

* Fixes for build with the new pytorch

* mac arm64(m1)

* linting

* # Compile for mac arm64

* # Compile for mac arm64

* removing .DS_Store

* Mark exported symbols with `SPARSE_API` so they are available in the DLL on WIndows.

* Export symbols by default in the Python library.

* Sync headers with implementation.

* Include the `SPARSE_API` macro.

* Fix linting issue.

* Add `WITH_PYTHON` to conditionally link to Python.

* Only include `Python.h` when WITH_PYTHON is set.

* Avoid including extensions.h as it includes Python.h.

* Better way to include `getpid()`.

* Define `WITH_PYTHON` when building with setup.py.

* Only include Pyinit when building with Python.

* Only include Pyinit when building with Python.

* Uses the `trust_data` invariant to skip blocking assertions, when unnecessary, during construction of `SparseStorage` objects.
* Refactors the dtype and device transfer APIs to align with `torch.Tensor` while maintaining backward compatibility.
* No longer constructs dummy tensors when changing dtype or device.

* fix(`SparseTensor.__getitem__`): support `np.ndarray` and fix `List[bool]`

support indexing with np.ndarray & fix bug merging from indexing with
List[bool]

* style(tensor, test_tensor): pep8 E501 too long

support indexing with np.ndarray & fix bug merging from indexing
with
List[bool]

* update

* typo

* typo
Co-authored-by: tim <dbwtimteo@outlook.com>
Co-authored-by: rusty1s <matthias.fey@tu-dortmund.de>

* Create spadd.py

Hi,
Maybe it's trivial to have this function, but I still think it'll be helpful and it looks neat when applying matrix addition, i.e., C = A + B.
Thanks

* update

* update

* fix jit
Co-authored-by: rusty1s <matthias.fey@tu-dortmund.de>

Update storage.py

BUG: when sparse_sizes is passed with (None, None), this causes an error

Let torch determine correct cuda architecture

See `pytorch/torch/utils/cpp_extension.cpp:CUDAExtension`:
>   By default the extension will be compiled to run on all archs of the cards visible during the
>   building process of the extension, plus PTX. If down the road a new card is installed the
>   extension may need to be recompiled. If a visible card has a compute capability (CC) that's
>   newer than the newest version for which your nvcc can build fully-compiled binaries, Pytorch
>   will make nvcc fall back to building kernels with the newest version of PTX your nvcc does
>   support (see below for details on PTX).

>   You can override the default behavior using `TORCH_CUDA_ARCH_LIST` to explicitly specify which
>   CCs you want the extension to support:

>   TORCH_CUDA_ARCH_LIST="6.1 8.6" python build_my_extension.py
>   TORCH_CUDA_ARCH_LIST="5.2 6.0 6.1 7.0 7.5 8.0 8.6+PTX" python build_my_extension.py

>   The +PTX option causes extension kernel binaries to include PTX instructions for the specified
>   CC. PTX is an intermediate representation that allows kernels to runtime-compile for any CC >=
>   the specified CC (for example, 8.6+PTX generates PTX that can runtime-compile for any GPU with
>   CC >= 8.6). This improves your binary's forward compatibility. However, relying on older PTX to
>   provide forward compat by runtime-compiling for newer CCs can modestly reduce performance on
>   those newer CCs. If you know exact CC(s) of the GPUs you want to target, you're always better
>   off specifying them individually. For example, if you want your extension to run on 8.0 and 8.6,
>   "8.0+PTX" would work functionally because it includes PTX that can runtime-compile for 8.6, but
>   "8.0 8.6" would be better.

>   Note that while it's possible to include all supported archs, the more archs get included the
>   slower the building process will be, as it will build a separate kernel image for each arch.