WIP: Use StridedDiscreteDomain with SplineBuilder#892
WIP: Use StridedDiscreteDomain with SplineBuilder#892EmilyBourne wants to merge 5 commits intomainfrom
Conversation
| std::optional(derivs_strided[interpolation_domain.front()].span_cview()), | ||
| std::optional(derivs_strided[interpolation_domain.back()].span_cview())); |
There was a problem hiding this comment.
I think a way to properly do this would be to do a cartesian product between a 1D strided domain and a 1D contiguous domain. Once you slice by a DiscreteElement in the strided dimension you would recover the contiguous domain over derivatives.
There was a problem hiding this comment.
We could allow strided domains in the spline operator but it feels artificial, the operator still requires all derivatives, so it would work only when the stride is unitary.
There was a problem hiding this comment.
I think a way to properly do this would be to do a cartesian product between a 1D strided domain and a 1D contiguous domain
I agree. I couldn't find a way to do this though. I guess it's not possible right now?
There was a problem hiding this comment.
We could allow strided domains in the spline operator but it feels artificial, the operator still requires all derivatives, so it would work only when the stride is unitary.
Yes. If a cross product of strided and unstrided domains was possible then there would be no need to allow strides domains here.
However I wonder if it is worth considering keeping this in mind for the handling of ND splines. If I had to pass derivs_strided here instead of derivs_strided[front] and derivs_strided[back] then it would be much easier to calculate the number of arguments required for the ND case (N! N(N+1)/2 derivatives+ 1 argument for the values)
There was a problem hiding this comment.
I guess it's not possible right now?
No indeed, but this is something to work on to be able to release v1 in my opinion.
it would be much easier to calculate the number of arguments required for the ND case (N! derivatives+ 1 argument for the values)
Do you claim that it is possible to pass all derivatives in one chunkspan ? Still we would need to check at runtime that the dimension of derivatives has unitary stride right ?
If we had this product feature, in 2D we could consider passing a single
ChunkSpan<double, Product<StridedDiscreteDomain<DDimI1>, DiscreteDomain<Deriv<I1>>>> derivs_dim1;instead of two arrays derivs_min1 and derivs_max1. Do you think we can do better than this with only Chunk/ChunkSpan data structures ? This would also allow to check that the user passes derivatives at the correct location ?
There was a problem hiding this comment.
Do you claim that it is possible to pass all derivatives in one chunkspan ?
Not all derivatives, but all derivatives of the same type. So 3 chunks for 2D:
derivs1 (domain = derivs2 (domain = cross_derivs (domain =
Still we would need to check at runtime that the dimension of derivatives has unitary stride right ?
Yes probably. This could be in an assert I guess?
There was a problem hiding this comment.
The formula for the number of derivatives required is:
if we pass all derivatives of the same type in one chunkspan.
If we pass explicitly as we have done up to now the formula is:
| N | N derivs with strided | N derivs without strided |
|---|---|---|
| 1 | 1 | 2 |
| 2 | 3 | 8 |
| 3 | 7 | 26 |
| 4 | 15 | 80 |
| 5 | 31 | 242 |
There was a problem hiding this comment.
Still we would need to check at runtime that the dimension of derivatives has unitary stride right ?
Yes probably. This could be in an assert I guess?
Yes we can but my point is to say that we need to develop this product feature. We cannot propagate too many unnecessary StridedDiscreteDomain, there could be a performance penalty.
No description provided.