What triggers recompilation for sparse input?

[krzysztofrusek]

In simple trials I have found that recompilation is triggered based on the shape of array i.e. just like for dense counterparts.
I just want to make sure if this is correct?

My second question is what is the recommended way to grow sparse array to a given shape ( not reshaping) as jnp.pad is not supported?

[jakevdp]

If you're talking about jax.experimental.sparse objects: compilation is cached based on the static metadata (i.e. shape and dtype) as well as changes to the shape and dtype of the dense buffers representing the sparse matrix.

Regarding your second question: it would be helpful if you could show example code demonstrating the type of operation you'd like to do.

[jakevdp]

Actually, I realized there is a way around that: you could pre-allocate the full graph, but mask out the part of the matrix you don't need (any index value greater or equal to the axis dimension will be treated as a masked value by the sparse implementations) then when you add new nodes, you could add them by converting these masked entries into defined entries.

There are no high-level utilities for this, so to accomplish it you'd have to work with the underlying data and indices buffers directly. Hope that helps!

[krzysztofrusek]

Interesting idea, and not that obvious. Maybe you should add this to the documentation of sparse module together with your previous answer about recompilation.

[jakevdp]

Yeah – the sparse docs are pretty incomplete, but it's an experimental implementation and we don't intend full support.

[krzysztofrusek]

Any plans to make it stable? Otherwise everything based on jax.sparse will alse be experimental.
This equation started with the intention simplify the interface to my library queuinx and use it once sparse is stable.

[jakevdp]

At this point there are no definite plans for further development of jax.experimental.sparse. The main problem is that XLA has no sparse primitives, and so the performance of the sparse operations is very slow. Given that, we did not find enough real-world use-cases of the tools to justify further development.