# Sparse high dimensional array support einsum?

**URL:** https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222
**Category:** Numerics
**Tags:** question, package
**Created:** [September 24, 2020, 5:34pm UTC](https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222 "2020-09-24T17:34:42Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![yupbank](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yupbank/32/18173_2.png) [@yupbank](https://discourse.julialang.org/u/yupbank)
#### Post date: [September 24, 2020, 5:34pm UTC](https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222/1 "2020-09-24T17:34:42Z")

</div>

Hello there,

I’m wondering if there is any effort in high dimensional sparse tensors with einsum support?

For example, I’m working on something that can be abstracted into high dimensional tensors and i need to perform contraction with it a lot.

One tensor I’m working with has d=100 dimensions.  
T \in \mathbb{R}^{10 \times 10 \times 10 \cdots \times 10}, and only a few million of the elements have non-zero value. If i were to work with the dense Tensor, i would need to operate on 10^{100} elements. Which is expensive and non-ideal.

What i have are values with indexes. E.g. the first non zeros element was represented using a big index vector and a value vector (j\_1, \cdots, j\_{d-1}), (v\_1, \cdots, v\_{10}) such that j\_i \in \{1 \cdots 10\}

---

<div class="post-metadata">

### Author: ![zyth0s](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zyth0s/32/19042_2.png) [@zyth0s](https://discourse.julialang.org/u/zyth0s)
#### Post date: [September 24, 2020, 6:32pm UTC](https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222/2 "2020-09-24T18:32:45Z")

</div>

There are some packages that provide support for Einstein summation notation:

- [TensorOperations.jl](https://github.com/Jutho/TensorOperations.jl)
- [Einsum.jl](https://github.com/ahwillia/Einsum.jl)
- [Tullio.jl](https://github.com/mcabbott/Tullio.jl)
- [ITensors.jl](https://github.com/ITensor/ITensors.jl)

---

<div class="post-metadata">

### Author: ![yupbank](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yupbank/32/18173_2.png) [@yupbank](https://discourse.julialang.org/u/yupbank)
#### Post date: [September 24, 2020, 6:55pm UTC](https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222/3 "2020-09-24T18:55:48Z")

</div>

thanks, I was looking at those, but none of them have sparse support.

---

<div class="post-metadata">

### Author: ![mcabbott](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mcabbott/32/6603_2.png) [@mcabbott](https://discourse.julialang.org/u/mcabbott)
#### Post date: [September 24, 2020, 7:45pm UTC](https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222/4 "2020-09-24T19:45:04Z")

</div>

I don’t think there is, and I thought that generalising what works for sparse matrices was pretty tricky. Did you find [https://github.com/tensor-compiler/taco](https://github.com/tensor-compiler/taco)?

But with 100 indices, I guess you will need some other notation than writing them all out… what operations are you actually performing on these things? Maybe they are better thought of as dataframes or something?

---

<div class="post-metadata">

### Author: ![yupbank](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yupbank/32/18173_2.png) [@yupbank](https://discourse.julialang.org/u/yupbank)
#### Post date: [September 24, 2020, 7:51pm UTC](https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222/5 "2020-09-24T19:51:37Z")

</div>

yeah, there are in dataframe right now. somehow einsum has much compact expression of the things i’m trying to achieve.  
the operation i’m doing is simply  
i \cdots j \to ij, where i ranges from 1 to d-1 .

---

<div class="post-metadata">

### Author: ![mcabbott](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mcabbott/32/6603_2.png) [@mcabbott](https://discourse.julialang.org/u/mcabbott)
#### Post date: [September 24, 2020, 8:13pm UTC](https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222/6 "2020-09-24T20:13:29Z")

</div>

Do you mean that you sum over all indices except the first and last? `i` there looks like it runs from 1 to 10, not 100. (But something else could label which indices don’t get summed, the `n`th & `m`th.) You could write this, but there’s little to gain over writing the loops yourself:

```julia
julia> inds = rand(1:10, 333, 100); vals = randn(333);
julia> out = zeros(10,10);
julia> using Tullio

julia> @tullio out[inds[r,1], inds[r,100]] += vals[r]

```

---

<div class="post-metadata">

### Author: ![juthohaegeman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juthohaegeman/32/8620_2.png) [@juthohaegeman](https://discourse.julialang.org/u/juthohaegeman)
#### Post date: [September 24, 2020, 9:51pm UTC](https://discourse.julialang.org/t/sparse-high-dimensional-array-support-einsum/47222/7 "2020-09-24T21:51:30Z")

</div>

There is a `SparseArray` type in the master branch of TensorOperations.jl that is compatible with the `@tensor` macro for tensor contractions. It uses a dictionary to store the non-zero values (i.e. a Dictionary Of Keys sparse array). However, the implementation is:

- untested
- incomplete
- undocumented
- not yet exported

All of these will hopefully be remedied in the near future, as this is needed for some of my own work. However, I am contemplating about such things as: the most appropriate name for this type, the best place to put it (inside TensorOperations.jl or as a separate package), …

However, be warned: I am using a tuple of indices as the keys in the dictionary, which I manipulate using the functionality of TupleTools.jl. In your use case this amounts to working with tuples of length 100. I am not sure this will be efficient. And even if the actual runtime is efficient, it might lead to huge compilation times.
