Skip to content
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

WIP: in-place interpolations #34

Closed
wants to merge 3 commits into from
Closed

WIP: in-place interpolations #34

wants to merge 3 commits into from

Conversation

timholy
Copy link
Member

@timholy timholy commented May 16, 2015

As perhaps you can tell, I'm making a push to replace some of my practical uses of Grid with Interpolations. I think the last remaining hangup is that I have situations in which I've pre-allocated a bunch of SharedArrays for the coefficients, and hence (if I'm going to get the multi-processing benefit of these SharedArrays) need the ability to do interpolation using in-place (destructive) processing.

This is a first stab at achieving this. The messiest part of this is passing both the full interpolation-type and the OnCell/OnGrid status to extrap_transform_x. I can clean that up if you otherwise think this basic idea is acceptable. (And add documentation, etc.)

To clarify one important aspect of the behavior: for Quadratic{Interior,OnGrid}, the interpolation can only be evaluated over the domain [1.5+eps,size(A,d)-0.5-eps]. I'm personally prepared to live with that, but I wanted you to be aware of this.

This isn't a huge improvement, but in my tests it allocates about
seven-fold less memory and runs in approximately 60% of the
time of the original. The improvement is much more dramatic for
cases where it doesn't have to use Woodbury, in which case it's more
than 5x faster.
@tomasaschan
Copy link
Contributor

This is a nice idea, which I have been experimenting a little with myself. I'm not sure if I understand the ramifications of your note on Quadratic, though; is it that no extrapolation is possible, or is it that evaluation is impossible also on the domain edges? I can live with either, but it would have to be very clearly documented (preferrably in terms of a very helpful error message when doing the "wrong" thing).

Also, have you seen #31? With those API changes I believe it will be much easier to incorporate these ideas in the interface, since interpolation and extrapolation will be even more clearly separated there. I've been trying to get to completing that PR, but time is a precious resource. Much of the functionality is in place, but the test suite has to be completely rewritten because of the API changes; I haven't felt comfortable merging such substantial changes with neither good test coverage nor a review from someone else...

@timholy
Copy link
Member Author

timholy commented May 17, 2015

The plan was it wouldn't be evaluated on the edges, either. One could evaluate it on the edge by modifying the tridiagonal system and having ixm_d = max(1, ixm_d). But I was trying to minimize the number of operations, and in exchange I'm happy to lose the ability to evaluate on the edge.

@timholy
Copy link
Member Author

timholy commented May 29, 2015

Superseded by #36.

@timholy timholy closed this May 29, 2015
@timholy timholy deleted the teh/inplace branch August 7, 2015 22:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants