Multi-valued interpolation

[timholy]

One of the things worth considering is "value dimensions" of an array. This was mentioned here. At one point I considered suggesting that any "value dimension" should just be an immutable (like the immutables of Color), but this issue completely dashes that thought (200,000 fields would be a lot of typing...).

So we are left with 3 potential approaches:

• As suggested in the second bullet point, use Arrays as the element types. One problem:

julia> function f(n)
           a = [n]
           nothing
       end
f (generic function with 1 method)

julia> f(3)

julia> @allocated f(3)
64

That's a lot of memory overhead for an element that only needs 8 bytes.

• Use tuples. That limits us to 1d objects, and currently these too have overhead, but I think not as much as Arrays (it's harder to measure because sometimes they are elided, which is of course nice when it's applicable).
• Add a ValueDims<:(Int,...) parameter to the AbstractInterpolation type. This would encode value dimensions in a way that we could dispatch on them. Of course we'd want to do some simple performance testing before adopting this route. Our metaprogramming would have to be even more generic, generating different versions of the code for different choices of the ValueDims tuple.

[tomasaschan]

If memory overhead for arrays is a problem, maybe the user can use ImmutableArrays.jl instead? Those only cover quite small arrays, but I imagine that the overhead becomes insignificant (?) for larger arrays. In any case, if we duck-type it, the user can choose a data structure that suits their needs (of simplicity and/or memory management) and have it Just Work(TM).

[timholy]

ImmutableArrays are basically what I was thinking up at the very top, and indeed they don't have any overhead whatsoever. But since ImmutableArrays don't extend up to vectors of length 200_000, we'll need to find another way. The FixedArrays I've been working on (JuliaLang/julia#7568) are basically an alternative implementation of ImmutableArrays that might, someday, scale.

Besides immutables, I don't know of another type that can be packed efficiently, so there could be a hard decision ahead. I'm really torn between make-the-user-use-a-vectorlike-element-type and declaring-one-or-more-dimensions-as-being-value-dimensions. I tend to think that the latter solution would work today, but just doesn't feel like the direction we want to go long-term.

[tomasaschan]

Just a thought: how difficult would it be to support both? In other words, making interpolation with a single value dimension work also for vector-like element types, while having an API for declaring multiple dimensions as value dimensions alongside it, letting the user make the decision on what is best for them?

[timholy]

There's almost nothing needed to support vector-valued arrays; as long as f*A[1] + (1-f)*A[2] yields the right thing, you're done. If we decide to support value dimensions in arrays, that won't conflict with the former. So you're right, we can do both. We just need to decide whether we want to go to the trouble to support value dimensions. I'm personally in favor, I think.

[timholy]

My impression is that, for both of us, our current thinking is that multi-valued interpolation will be handled by multi-valued element types (tuples, immutables, or their generalization). So I'll close this.

[tomasaschan]

Yeah, I think so too. If we find a good use case for something like value dimensions in the future, we can always re-visit the decision.