Generalise _interpolate! to allow mixed dimensions

[rafaqz]

This PR is an exploration of #31 and #32 to see whats possible.

Probably quite slow in current form but this largely works already for the current tests.

The idea is to break each dimension into a preparation step, a definition of the iteration space, and then scaling and index generation functions for the inner loop, then call all of these function from the same shared _interpolate! method.

Will need to add some tests for mixed dimension types.

Closes #31 and closes #32

[SouthEndMusic]

I don't fully onderstand everything yet, but overall it looks good. I added some comments.

[rafaqz]

FYI there is a lot left to do, the tests that pass are because there are no missing dimensions but this will break if there are any.

[rafaqz]

This should be working now.

[rafaqz]

There are a few outstanding questions not - like #38 on what dimensions the weights matrix should have now.

But more importantly, what should ts in itp(ts) be ? For NoInterpolationDimension should it require an Int, Colon or AbstractArray{Int} ? To me that would be the most powerful approach, but others may disagree. The alternative would be as now with the trailing dimensions, non interpolated dims are just not included.

Currently Colons are inserted into ts internall to represent the non-interpolating dimensions. But it would be much more flexible if the colon could be an Int or AbstractArray so that _interpolate could be the core function for e.g. a DimensionalData.jl wrapper that allowed arbitrary mixed indexing.

Please chime in here this should be finalised and tested in this PR.

[SouthEndMusic]

It should be more clear that !valid_derivative_orders does not mean that the input is invalid but that it is certain that the output is 0.

[rafaqz]

What do you suggest

[SouthEndMusic]

Why allow the index to be any type?

[rafaqz]

It can be Colon() etc for NoInterpolationDimension.

Although this could all be cleaned up a bit.

[SouthEndMusic]

But more importantly, what should ts in itp(ts) be ? For NoInterpolationDimension should it require an Int, Colon or AbstractArray{Int} ? To me that would be the most powerful approach, but others may disagree. The alternative would be as now with the trailing dimensions, non interpolated dims are just not included.

Why not support multiple approaches? Have one method which calls _interpolate! with arguments that are most convenient for the internals, and several wrapper methods that convert other input formats to the internal one. We can dispatch on the number of arguments matching to N and N_in (The ambiguity for N = N_in can probably easily be dealt with), and a fallback method which gives an error that it doesn't match either.

[rafaqz]

Maybe, I was leaning to choosing one or the other because mixed tuple lengths both accepted in the same function may invite some user error and confusion.

[SouthEndMusic]

I am still in favor of supporting multiple options if reasonably possible. We could make the difference more explicit by using different functions or pass an optional Boolean flag. Then we still have to decide what the default behavior is. From a mathematical perspective I would prefer the current approach on main, but if passing some trivial object for the non-interpolated dimensions makes more sense from a code perspective, that's fine too.

[rafaqz]

A bool keyword on a tuple length isn't necessarily type stable unless it reliably constant props, and I would prefer simplicity over options, so making a choice either way seems better to me.

Given this difference of perspective its probably better discussed in a new PR and not hold up this one, so I kept the behavior as it was on main.

[rafaqz]

This seems good to go to me. I don't think its even a breaking change? I have some performance improvements too but will PR those when this lands.

(Please use squash if/when this is merged, there are a lot of small commits not intended for the history)