Apply along axis of array about finitediff

[bjodah]

Hi @tommym98, and thank you for your kind words.

finitediff assumes it is working with contiguous data, i.e., rows if the numpy array order is C and columns if the order is F. numpy has two functions to (internally) reorder 2D arrays as such:

• asfortranarray
• ascontiguousarray

those should be just as fast as if we loop manually in C++/Fortran. Then slices such as A[:, i] will be
contiguous when order='F' and slices such as A[i, :] will be contiguous when order='C'.

Another issue which I could see as a possible performance bottleneck is if one needs to call interpolate_by_finite_diff multiple times in a loop (is this your case?). Modifying interpolate_by_finite_diff to accept 2D arrays would be pretty straightforward.

As for 2D arrays, do you mean adding support for mixed derivatives? This would certainly be interesting, e.g. generating mimetic finite differences (respecting the product rule), but right now I don't have any immediate plans to explore that.

[twmitchel]

Thanks for getting back to me so quickly @bjodah , I really appreciate it.

Reading it now, I realize my original question was slightly unclear. By 1-D arrays, I was referring to numpy arrays of size (1, n) or (n, 1), essentially single vectors. By 2-D arrays, I meant arrays of shape (m, n) where m, n > 1. I apologize for the confusion and my poorly worded question.

In particular, I was referring to the performance bottleneck you mentioned when calling interpolate_by_finite_diff multiple times in a loop, as in iterating it over the rows of a large numpy array in Python. Before going around and messing with the internals of your package (my last resort) I wanted to double check and make sure I wasn't overlooking a way of structuring the inputs that would allow me to do this.

Now that it's clear modifying interpolate_by_finite_diff is necessary, I'm happy to go ahead with it. However, if it doesn't take too much time on your end and if you're willing to do so, I think that adding this functionality to the module (with a focus on maximizing speed) would be really important. In particular, this would give interpolate_by_finite_diff functionality akin to numpy.gradient. In combination with the amazing stability Fornberg's method and your code's wonderful ability to give the user fine control over the window size and order of derivation, I think this would make your package hugely valuable to many people (even more than it already is!).

All the best, and I look forward to exploring some of your other packages and seeing the new things you come up with as well. Keep up the great work!

[bjodah]

Feel free to re-open if the new feature doesn't fix the performance issue.

[twmitchel]

@bjodah, I'm so sorry for the delayed response - I've had a very busy couple of weeks.

I just performed some simple run time tests comparing the finitediff.interpolate_by_finite_diff module (maxorder = 0 & maxorder = 1) to scipy.interpolate.interp1d & numpy.gradient with great results:

Mean run time taken over 2500 randomly selected+parameterized curves across a range of time instances, real trajectories & video sequences from the Weizmann Action Recognition Database

I think these excellent results, especially considering that numpy.gradient requires regularly spaced data. This is really absolute gold for computing near real-time trajectory dynamics using coarsely sampled data (e.g. for robot control w/ Aruco tags, analysis of real-time RGB+D skeletons, really any real-time or post processing analysis of experimental kinematic data, etc) where high-order finite difference approximation of derivatives are key. People would probably want to use some sort of patched-based 3-D interpolation/optical flow-based differentiation for video sequences, so the drop off in run time performance for very high dimensional signals (the Weizmann videos are relatively small for videos, ~ 140 x 180 = 25200 pixels per frame) isn't a big deal in my opinion.

Thank you so much for everything you've done with this package, continuing to update and maintain it, and especially for your responsiveness. Cheers!

*edited for clarity

[bjodah]

@tommym98 I'm really glad to hear that it's working out for you. It might be worthwhile to experiment with compile flags to squeeze out the last bit of performance:

$ rm -r build/
$ CFLAGS="-O3 -ffast-math -march=native -funroll-loops" ./setup.py install

Those benchmark results look really interesting. If you want to add any benchmarks to the repository I'm open to that (for continuous benchmarking).

I added a Zenodo DOI to the README (to cite for reproducibility).

[twmitchel]

Hi @bjodah, I hope that you've been well.

Unfortunately, I may have spoken too soon in giving the all clear as on closer inspection I'm having trouble getting interpolate_by_finite_diff module to work accurately and am getting strange values for derivative estimates. I wasn't able to detect this at first due to another bug in my own code but having fixed that, I'm not sure if the module is working correctly.

To this point, I've noticed that the example you give in the _finitediff_c.pyx under interpolate_by_finite_diff, e.g.

   >>> x = np.array([0, 1, 2])
   >>> y = np.array([[2, 3, 5], [3, 4, 7], [7, 8, 9], [3, 4, 6]])
   >>> xout = np.linspace(0.5, 1.5, 5)
   >>> r = ifd(x, y, xout, maxorder=2)

returns a NaN array for r, at least on my machine. I'm not sure if this is related to the larger problem I'm experiencing with the module, but when you get the chance would you mind running it on your system to see if it works for you? If it does, I'll assume the problem is on my end and see if I can't figure it out.

Thanks as always!

[bjodah]

Oh, I can reproduce this. I'm surprised this slipped through the test suite, sorry about that. I'm currently working on fixing this (this may be the cause of an issue I've been having with one of my own codes using this library).