I was confused, we don't need to fix this asap as the np devs are trying to not break us (and are converting errors to warnings).

@tacaswell, it's not 100% essential to fix it immediately--but it is very much the right thing to do, and it should be do-able. Thanks for writing the PR.

@tacaswell, it looks like a random Travis failure on 3.2, unrelated to the PR.

@efiring It's not random, it happens every time. Something is going wrong in the setup script and I'm pretty sure that it is from the Qt5 support merge.

I have been holding off on tracking it down on the hope that we would just drop support for 3.2 (IPython has) so it wouldn't be a problem.

Given how slow our release cycle is, we definitely should fix this now for
1.4.0.

On Sat, Jul 5, 2014 at 8:32 PM, Eric Firing [email protected]
wrote:

@tacaswell https://github.com/tacaswell, it's not 100% essential to fix
it immediately--but it is very much the right thing to do, and it should be
do-able. Thanks for writing the PR.

—
Reply to this email directly or view it on GitHub
#3188 (comment)
.

@tacaswell Thanks for coming up with a candidate fix; I hope to take a look at it tomorrow evening. We should also ask @GBillotey to take a look at it as he wrote lots of the original code.

I am reviewing it right now as well. I am wondering if we are papering over a deeper problem.

Indeed, there is a deeper issue. The issue occurs when doing the CubicTriInterpolator with return key of "dxdz" or "dzdx". This goes through a different code path that calculates the jacobian. It appears that it is expecting the returned result to be Nx2, but it is coming back as 1xNx2. The slicing returns a 1xN array when it should be just a length N array.

Correction... it produces Nx2x1 arrays, and the slicing produces Nx1 arrays.

OK, I have taken a look at this. The changes to trirefine.py are fine.

Thanks to @WeatherGod for finding the root cause of the other issue. To clarify, the Nx2x1 array is returned from _ReducedHCT_Element.get_function_derivatives, and as it explicitly states it does this I don't want to alter it. The function is only ever called by CubicTriInterpolator._interpolate_single_key, in the elif block, line 462. Hence rather than adding the ravel at line 213 of triinterpolate.py, which will change a number of other code paths, I would instead prefer to alter line 465 from return dzdx[:, 0] to return dzdx[:, 0, 0] and similar for line 467.

I have confirmed that with these changes we no longer get the FutureWarnings when running the tests and examples using the latest numpy master, and the rather older numpy 1.6 is fine.

@tacaswell: If you would rather I just wrote another PR with these changes rather than you modifying this one then let me know.

Please write a PR against this one.

@tacaswell The failure on 3.2 appears to be related to this bug which reports it to be a problem between garbage collection and Finalizer callbacks. The changeset was applied to 2.7 and to the 'default' branch on 25 May 2012, which is after the 3.2 release date (but before 3.3).

The fix would be to either avoid multiprocessing on 3.2 (although Gtk3 uses it also) or catch the exception that is thrown and carry on regardless. That would allow the build to complete. If support for 3.2 is staying I'm happy to fix this up and submit a PR.

@mfitzp Thanks for tracking this down! A PR would be great.

I think we are planning to stop testing on 3.2, but it would be good to not leave the (hopefully small) 3.2 user base in the lurch.