refactor: add output dimensionality as a parameter in AbstractInterpolations #342
Conversation
sathvikbhagavan
force-pushed
the
sb/output_dim
branch
2 times, most recently
from
6ab798f to
59ada74
Compare
sathvikbhagavan
force-pushed
the
sb/output_dim
branch
from
59ada74 to
1df1996
Compare
sathvikbhagavan
force-pushed
the
sb/output_dim
branch
from
c6184f8 to
a79f1fe
Compare
| function get_output_dim(u::AbstractVector) | ||
| return (length(first(u)),) | ||
| end | ||
|
|
||
| function get_output_dim(u::AbstractArray) | ||
| return size(u)[1:(end - 1)] | ||
| end |
There was a problem hiding this comment.
@sathvikbhagavan @ChrisRackauckas This breaks type inference of the constructors which causes problems in my downstream package (see #389). One way around this would be to allow (require?) users to specify the dimension as a type parameter when constructing the interpolation method.
However, it's not clear to me why this type parameter should be included at all. Arguably it also doesn't make sense at all for nonnumeric types (that I actually encounter when working with ConstantInterpolation). Would it be OK to revert this change?
If the output dimension is actually of interest to someone then it seems easy enough for them to use the logic of get_output_dim directly. Possibly this could also be made official by adding something like output_dim to the API (if actually necessary). This could also e.g. error for non-numeric types.
fixes: #328