-
-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
ENH: implement Akima interpolation in 1D #3112
Conversation
Otherwise, looks OK. |
Coverage remained the same when pulling dfcbcb9469f816bffc27e92fb86e46358b57d945 on andreas-h:Akima1D into f86894e on scipy:master. |
Coverage remained the same when pulling dfcbcb9469f816bffc27e92fb86e46358b57d945 on andreas-h:Akima1D into f86894e on scipy:master. |
coeff[1] = c | ||
coeff[0] = d | ||
|
||
PPoly.__init__(self, coeff, x, extrapolate=False) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a super
call would play better with subclassing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, mea culpa
I think you want super(Akima1D, self).__(coeff, x)
Periodic boundary conditions: https://gist.github.com/ev-br/7110020 |
Thanks for the pointer to your code. If you want me to, I can prepare a seperate PR to include periodic boundary conditions for |
Updated subclassing to use |
Feel free to do whatever you feel like with these lines of code. An optional enhancement would be to clarify the relation of the Akima splines and Irrespective of this, I'm +1 on this PR. |
One thing needs to be added: it should support multidimensional y-arrays, not only 1D. This feature is very often needed. |
I agree multidimensional
I'm not sure where this comes from, but it might be because the As an alternative approach to this, I could go a different route: implement the Akima algorithm in a helper class |
It would probably be enough to support n-d so that the interpolation axis is the first one. The PPoly/BPoly can handle this, so in Akima the only thing to do is to make sure the coefficient computation is vectorized accordingly. |
The current code in If the axis transposition is a feature that could be useful, it should be added in PPoly. There's no need to inherit from |
Done; Is there a more elegant way to do the "broadcasting" I'm doing in l. 1433-1435? It feels hackish what I'm doing there. |
Sorry, just realized I amended my changes to the last commit and did a --force push. Seems like I'm still doing stupid things with git ... :-/ |
# determine slopes between breakpoints | ||
m = np.empty((x.size + 3, ) + y.shape[1:]) | ||
dx = np.diff(x) | ||
for i in range(y.ndim - 1): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Equivalent to dx = dx[(slice(None),) + (None,)*(y.ndim-1)]
?
If so, better not use as_strided
Force-pushing to pull requests is also OK |
If this is okay, can we get it into 0.14? |
I'll (i) rebase, (ii) rename to AkimaInterpolator, and (iii) move the implementation to _monotone.py together with pchip |
Could you also add a 'see also' crosslinks to both docstrings. |
Ok, actually this has to wait for tomorrow from my side, got to go... |
y : ndarray, shape (m, ...) | ||
N-D array of real values. The length of *y* along the first axis must | ||
be equal to the length of *x*. | ||
axis : int, optional |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left over? The init below does not seem to have an axis
argument (I realize I'm a little late to the party...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True ... will force-push fix
(this is by no means intended to block merging) Can you comment on this: https://gist.github.com/ev-br/9081651 I've to admit I did not read Akima's paper, but I somehow had an impression that akima splines were supposed to not overshoot? |
interesting. I'll need to check, hopefully tomorrow. I know Akima's are supposed not to overshoot, but I don't remember if they're guaranteed not to do so. Have to go now, but will come back to this very soon. |
Handling of arbitrary axis can be done in a way similar to |
I think the implementation here is correct. I get the same overshooting curve from other Akima implementations, so it's a property of the algorithm. |
Thanks a lot Andreas! PR merged in 358d1aa. |
As promised in #2885, here's my PR for Akima interpolation in 1D. While there are several improvements thinkable, I believe it's already useful as-is and would appreciate inclusion in the upcoming 0.14 release.