-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-valued interpolation #3
Comments
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). |
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. |
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? |
There's almost nothing needed to support vector-valued arrays; as long as |
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. |
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. |
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:
That's a lot of memory overhead for an element that only needs 8 bytes.
ValueDims<:(Int,...)
parameter to theAbstractInterpolation
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 theValueDims
tuple.The text was updated successfully, but these errors were encountered: