matplotlib-devel Mailing List for matplotlib

The current implementation of Delaunay interpolator returns NaN for grids
whose x or y has dimension 1 (i.e. when you try to interpolate along a
horizontal/vertical line, or in a single point). See example below.
By looking at the code, it seems that this can be fixed by simple
rearrangement of calculations.
Suggested patch provided here:
https://github.com/AmitAronovitch/matplotlib/commit/f312d864da9c72681eb3db3b5920ae64793c713e(let
me know if you want a pull request).
The suggested implementation is almost identical. It might actually perform
faster in some cases (there is one less multiplication op in the inner
loop). There might be some differences in accuracy, but I believe they
should only become observable in cases where the grid size is very large
(which would probably cause memory problems anyway).
Example (before suggested patch):
>>> from matplotlib.delaunay import Triangulation
>>> tri = Triangulation([0,10,10,0],[0,0,10,10])
>>> lin = tri.linear_interpolator([1,10,5,2.0])
>>> # 2x2 grid works fine
>>> lin[3:6:2j,1:4:2j]
array([[ 1.6, 3.1],
 [ 1.9, 2.8]])
>>> # but not when 1x2, 2x1, 1x1:
>>> lin[3:6:2j,1:1:1j]
array([[ nan],
 [ nan]])
>>> lin[3:3:1j,1:1:1j]
array([[ nan]])
>>>
After suggested patch:
>>> from matplotlib.delaunay import Triangulation
>>> tri = Triangulation([0,10,10,0],[0,0,10,10])
>>> lin = tri.linear_interpolator([1,10,5,2.0])
>>> # 2x2 grid: same same
>>> lin[3:6:2j,1:4:2j]
array([[ 1.6, 3.1],
 [ 1.9, 2.8]])
>>> # but these work now
>>> lin[3:6:2j,1:1:1j]
array([[ 1.6],
 [ 1.9]])
>>> lin[3:3:1j,1:1:1j]
array([[ 1.6]])
>>>

On 06.07.2012, at 3:49PM, Damon McDougall wrote:
>> 
>> When I tested on Mac OS X 10.6 I found that most unit tests were somehow 
>> missing. Rather than try to diagnose the problem, I built a new binary 
>> on 10.6, confirmed that it installed properly (with all unit tests) on 
>> 10.6 and 10.7, then uploaded it to replace the earlier 10.6 binary.
>> 
>> The same test I mentioned in my previous post still fails using the new 
>> binary, on both 10.6 and 10.7.
>> 
>> -- Russell
>> 
> 
> I did a git checkout of the v1.1.1 tag and compiled a 64-bit version. I
> have attached output from the following command:
> 
> python -c "import matplotlib as m ; m.test(verbosity=1)"
> 
> Note that some of the tests fail with satuses: KEFKK.
> I have the following requirements installed:
> 
> nose: version 1.1.2
> PIL: version 1.1.7
> ghsotscript: version 9.05
> inkscape: 0.48.3.1
> 
> All of these were installed using the latest version of macports.
> Is there anything I can do to improve the output of the tests?
I see the same 3 known failures building with fink and the same versions of the above 
dependencies, and also get the already mentioned Stix failure. Everything else succeeds 
on 10.5, but I get a different inkscape error on 10.7:
+++++
IOError: Conversion command failed:
inkscape -z /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2.svg --export-png /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2_svg.png
Standard output:
Background RRGGBBAA: ffffff00
Area 0:0:720:540 exported to 720 x 540 pixels (90 dpi)
Bitmap saved as: /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2_svg.png
Standard error:
(inkscape:25527): libgnomevfs-WARNING **: Unable to create ~/.gnome2 directory: Permission denied
File display/nr-arena-item.cpp line 147 (?): Assertion child->parent == NULL failed
**
ERROR:sp-clippath.cpp:308:void sp_clippath_hide(SPClipPath*, unsigned int): code should not be reached
Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.
** Message: Error: Inkscape encountered an internal error and will close now.
+++++
This is obviously an inscape bug to be reported it to its respective maintainers. 
I found that on the Inkscape web site 0.48.2 is advertised as the stable release, 
so I tried downgrading to that version, but just get a similar crash on a different file.
Cheers,
					Derek

On Tue, Jul 3, 2012 at 11:18 AM, Ryan May <rm...@gm...> wrote:
> On Tue, Jul 3, 2012 at 10:03 AM, Tony Yu <ts...@gm...> wrote:
> >
> >
> > On Tue, Jul 3, 2012 at 10:22 AM, Ryan May <rm...@gm...> wrote:
> >>
> >> On Tue, Jul 3, 2012 at 9:14 AM, Tony Yu <ts...@gm...> wrote:
> >> > On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu <ts...@gm...> wrote:
>
> >> >> I finally had some time to revisit this issue. It seems that
> subprocess
> >> >> PIPEs have fairly limited buffers [1] (also see docs for
> >> >> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a
> >> >> decent
> >> >> amount of output to stderr. A simple solution is to redirect stderr
> to
> >> >> a
> >> >> temporary file. This change fixes the issue on my system.
> >> >>
> >> >> If this bug is reproducible, I can submit a PR. The temporary file
> here
> >> >> could be created using tempfile so it gets cleaned up automatically,
> or
> >> >> maybe a more permanent log file for debugging. Thoughts?
> >> >>
> >> >> -Tony
> >> >>
> >> >> [1]
> >> >>
> >> >>
> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
> >> >>
> >> >> [2]
> >> >>
> >> >>
> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
> >> >>
> >> >
> >> > And just to clarify: My original email mentioned that saving would
> hang
> >> > only
> >> > when `streamplot` was used to create the figure. It turns out that
> >> > ffmpeg
> >> > prints more output (keyframes?) for more complex images, so when I ran
> >> > simpler plots, they didn't produce enough output to fill the
> subprocess
> >> > `PIPE` (although they would eventually).
> >> >
> >> > Also, theres's a simpler fix than piping ffmpeg output to a file: Just
> >> > set
> >> > `-loglevel quiet` in the ffmpeg command.
> >> >
> >> > -Tony
> >>
> >> It's not a bad idea to have it logged to a file in a temp directory.
> >> We could potentially just do this if debug is set to verbose, however,
> >> and just use -loglevel quiet otherwise. Can you manage PR for this or
> >> do I need to?
> >>
> >> Ryan
> >>
> >
> > Hey Ryan,
> >
> > If you have time, that'd be great. Otherwise, I should have some time at
> the
> > end of the week to submit a PR.
> >
> > -Tony
> >
>
> I might be able to squeeze it in. If you don't see anything by the end
> of the week, hit me up.
>
> Ryan
>
>
Hey Ryan,
I didn't see a PR for this issue, so I just added a fix:
https://github.com/matplotlib/matplotlib/pull/989
As mentioned before, the PR suppresses logging in ffmpeg under normal
circumstances. When the verbosity level is set to debug, however, the
subprocess output (stdout + stderr) are piped to `sys.stdout`. This is
where verbose reports are posted, so I figured that was the best place (oh,
actually, I guess could have piped to `verbose.fileo`).
If you feel the debug output should go to a file instead, let me know.
Cheers,
-Tony