matplotlib-devel Mailing List for matplotlib

Hello all,
I have written a small patch which extends the functionality of
Figure.legend and pyplot.figlegend to match that of Axes.legend.
This patch allows figlegend to automatically build a legend for lines 
with the "label" property set when figlegend is called without a list of 
strings or object handles.
Also, the "loc" argument is made optional, and defaults to the upper 
right, same as Axes.legend.
I hope the attached patch is suitable for inclusion. I have also 
attached a test script showing each of the call signatures.
Thanks,
Ray Speth

On Mon, Mar 15, 2010 at 3:16 PM, klukas <kl...@wi...> wrote:
>
> It's my understanding that there is no built-in method for generating a
> "broken axis" (where you skip over some range of values, indicating this
> with some graphical mark). I wanted to do this, so I've put together a
> function which seems to be fairly robust, and I thought I might propose it
> as a starting point if there's interest in having a built-in facility for
> broken axes.
>
> Please let me know if this is not the appropriate place to be submitting
> this suggestion.
This is a nice start of an oft requested feature, and we are
definitely interested. It is enabled by the spine contribution of
Andrew, so you can turn off the upper and lower spines between the
break, so it is nice to see some unintended benefits of his
refactoring.
>From a usability standpoint, one thing we try to do is make pyplot a
thin wrapper around functionality that exists in the API proper in
matplotlib.figure, matplotlib.axes, etc. Functionally and in terms of
implementation, this broken axes implementation is in the style of
"twinx" which makes two axes for plotting on different scales
 http://matplotlib.sourceforge.net/examples/api/two_scales.html
 http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.twinx
 http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.twinx
What would be great is if you could refactor the basic functionality
into a matplotlib.Axes.breaky method (and possibly breakx but most
people request a broken y axis), which would resize the "self" axes
and return the broken compliment which could be plotted onto. Then
you could provide a thin pyplot wrapper much like pyplot.twinx, so
that pyplot as well as API users could benefit.
Finally, an svn patch which provided an example and patches to axes.py
and pyplot.py would be most helpful.
http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-patch
An alternative implementation could craft a custom transform using
some custom artists for spines, but this might be a good bit harder.
Do you have an opinion Andrew on this approach?
JDH

It's my understanding that there is no built-in method for generating a
"broken axis" (where you skip over some range of values, indicating this
with some graphical mark). I wanted to do this, so I've put together a
function which seems to be fairly robust, and I thought I might propose it
as a starting point if there's interest in having a built-in facility for
broken axes.
Please let me know if this is not the appropriate place to be submitting
this suggestion.
The basic idea of the below function is that you feed is an axes object
along with an iterable giving the bounds of each section of the y-axis. It
then returns new upper and lower axes objects, after masking spines,
calculating distances, etc. The only real problems here is that you need to
explicitly plot things on both the upper and lower axes, and then I haven't
figured out how to push out the y-axis label of the main axes object so it
doesn't overlap with the tick labels of the upper and lower axes. So, I
instead moved the y-labels of the upper and lower axes so that they appear
at the center of the axis, but this is problematic. Any thoughts on how to
do that part better?
http://old.nabble.com/file/p27909750/broken.png 
----------
from matplotlib import pyplot as plt
def axes_broken_y(axes, upper_frac=0.5, break_frac=0.02, ybounds=None,
 xlabel=None, ylabel=None):
 """
 Replace the current axes with a set of upper and lower axes.
 The new axes will be transparent, with a breakmark drawn between them. 
They
 share the x-axis. Returns (upper_axes, lower_axes).
 If ybounds=[ymin_lower, ymax_lower, ymin_upper, ymax_upper] is defined,
 upper_frac will be ignored, and the y-axis bounds will be fixed with the
 specified values.
 """
 def breakmarks(axes, y_min, y_max, xwidth=0.008):
 x1, y1, x2, y2 = axes.get_position().get_points().flatten().tolist()
 segment_height = (y_max - y_min) / 3.
 xoffsets = [0, +xwidth, -xwidth, 0]
 yvalues = [y_min + (i * segment_height) for i in range(4)]
 # Get color of y-axis
 for loc, spine in axes.spines.iteritems():
 if loc == 'left':
 color = spine.get_edgecolor()
 for x_position in [x1, x2]:
 line = matplotlib.lines.Line2D(
 [x_position + offset for offset in xoffsets], yvalues,
 transform=plt.gcf().transFigure, clip_on=False,
 color=color)
 axes.add_line(line)
 # Readjust upper_frac if ybounds are defined
 if ybounds:
 if len(ybounds) != 4:
 print "len(ybounds) != 4; aborting..."
 return
 ymin1, ymax1, ymin2, ymax2 = [float(value) for value in ybounds]
 data_height1, data_height2 = (ymax1 - ymin1), (ymax2 - ymin2)
 upper_frac = data_height2 / (data_height1 + data_height2)
 x1, y1, x2, y2 = axes.get_position().get_points().flatten().tolist()
 width = x2 - x1
 lower_height = (y2 - y1) * ((1 - upper_frac) - 0.5 * break_frac)
 upper_height = (y2 - y1) * (upper_frac - 0.5 * break_frac)
 upper_bottom = (y2 - y1) - upper_height + y1
 lower_axes = plt.axes([x1, y1, width, lower_height], axisbg='None')
 upper_axes = plt.axes([x1, upper_bottom, width, upper_height],
 axisbg='None', sharex=lower_axes)
 # Erase the edges between the axes
 for loc, spine in upper_axes.spines.iteritems():
 if loc == 'bottom':
 spine.set_color('none')
 for loc, spine in lower_axes.spines.iteritems():
 if loc == 'top':
 spine.set_color('none')
 upper_axes.get_xaxis().set_ticks_position('top')
 lower_axes.get_xaxis().set_ticks_position('bottom')
 plt.setp(upper_axes.get_xticklabels(), visible=False)
 breakmarks(upper_axes, y1 + lower_height, upper_bottom)
 # Set ylims if ybounds are defined
 if ybounds:
 lower_axes.set_ylim(ymin1, ymax1)
 upper_axes.set_ylim(ymin2, ymax2)
 lower_axes.set_autoscaley_on(False)
 upper_axes.set_autoscaley_on(False)
 upper_axes.yaxis.get_label().set_position((0, 1 - (0.5 /
(upper_frac/(1+break_frac)))))
 lower_axes.yaxis.get_label().set_position((0, 0.5 / ((1 -
upper_frac)/(1+break_frac))))
 # Make original axes invisible
 axes.set_xticks([])
 axes.set_yticks([])
 print upper_axes.yaxis.get_label().get_position()
 print lower_axes.yaxis.get_label().get_position()
 print axes.yaxis.get_label().get_position()
 print axes.yaxis.labelpad
 for loc, spine in axes.spines.iteritems():
 spine.set_color('none')
 return upper_axes, lower_axes
def prepare_efficiency(axes, lower_bound=0.69):
 """
 Set up an efficiency figure with breakmarks to indicate a suppressed
zero.
 The y-axis limits are set to (lower_bound, 1.0), as appropriate for an
 efficiency plot, and autoscaling is turned off.
 """
 upper_axes, lower_axes = axes_broken_y(axes, upper_frac=0.97)
 lower_axes.set_yticks([])
 upper_axes.set_ylim(lower_bound, 1.)
 upper_axes.set_autoscaley_on(False)
 return upper_axes, lower_axes
# test these
ax = plt.axes()
upper, lower = axes_broken_y(ax, ybounds=[-2., 2.9, 22.1, 30.])
upper.plot(range(30), range(30))
lower.plot(range(30), range(30))
upper.set_ylabel('Data')
plt.savefig('test')
-- 
View this message in context: http://old.nabble.com/Proposal-for-Broken-Axes-tp27909750p27909750.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Christopher Barker wrote:
> John Hunter wrote:
>> It would probably
>> be beneficial, but by no means required, to use CXX to expose the C++
>> part to python so take a look if you are inclined.
> 
> What about Cython -- is any one using Cython in MPL yet?
No, not yet, but I think we should be looking at moving in that 
direction. C++ support in cython is being introduced right now, if I 
understand correctly. I don't know what its limitations are, or how its 
ease of use and maintenance will compare with CXX.
Eric
> 
> -Chris
> 
> 

John Hunter wrote:
> It would probably
> be beneficial, but by no means required, to use CXX to expose the C++
> part to python so take a look if you are inclined.
What about Cython -- is any one using Cython in MPL yet?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Robert Kern wrote:
> On 2010年03月15日 13:30 PM, Ryan May wrote:
> Are you looking at making it possible to
>> construct a triangulation from the delaunay triangulation that is used
>> by griddata? (Sorry, I didn't follow the thread that closely.)
> 
> He's using matplotlib.delaunay.
> 
right, and the goal is to make it pretty easy to plug in another 
triangulation routine, or a pre-defined triangulation, if you have one.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Mon, Mar 15, 2010 at 12:37 PM, Ian Thomas <ian...@go...> wrote:
> Before going ahead with this I wished to ascertain how much interest
> there was for this functionality as I don't want to spend time doing
> something that isn't wanted or needed.
I'm definitely interested, but I defer to Eric as the ultimate arbiter
of all things contour related. I'm not concerned about the C++, we
depend on plenty of that and std C++ won't increase the compile or
distribution burden. I am a little concerned about the "hand wrapped
python" part because of the possibilities of introducing memory leaks
and difficulties it may pose in the matplotlib 2->3 transition. We
use CXX mostly to expose our C++ (eg see src/ft2font.cpp or
src/_backend_agg.cpp) and I'm hopeful that this will ease our
transition to python3 since CXX6 supports python3. It would probably
be beneficial, but by no means required, to use CXX to expose the C++
part to python so take a look if you are inclined.
I'm also a bit concerned by the maintenance aspect, since this is a
fairly sophisticated piece of code. We'd be looking for a commitment
to support it if we include it in mpl.

On 2010年03月15日 13:30 PM, Ryan May wrote:
> On Mon, Mar 15, 2010 at 12:37 PM, Ian Thomas<ian...@go...> wrote:
>> Ben Axelrod<BAx...@co...> wrote:
>>> I am a little unclear on what this is and what it is used for.
>>
>> It is used to generate contour plots for data that is defined on
>> unstructured triangular grids. Currently mpl supports generating
>> contour plots on regular rectangular grids; if you have an
>> unstructured grid you have to interpolate it onto a regular grid
>> before contouring it. Contouring directly from the triangular grid
>> avoids the need for this interpolation.
>
> Well then the meteorologist in me is an overwhelmingly +1 on having
> such functionality available. Are you looking at making it possible to
> construct a triangulation from the delaunay triangulation that is used
> by griddata? (Sorry, I didn't follow the thread that closely.)
He's using matplotlib.delaunay.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Ian Thomas wrote:
> Chris Barker wrote:
>> I think it would be great to have in MPL.
>>
>> What code are you using for the triangulation? Does it do constrained
>> delauney?
> 
> My code only does the contouring; you have to input the triangulation.
> In the examples included with the code I used matplotlib.delaunay to
> do the triangulations so as not to reinvent the wheel.
> 
> To include it in MPL, I would need to improve it somewhat (there are a
> couple of known bugs and insufficient documentation) and there would
> need to be a discussion of the API. At the moment I am using
> 
> tricontour(x, y, triangulation_indices, z, optional_mask)
> 
> followed by the usual contour args (N or V) and kwargs. Is this OK?
> I've also written utility plotting functions triplot, trifill and
> tripcolor; are these wanted?
> 
> In terms of implementation, at the python level I have a TriContourSet
> class which is the same as the existing ContourSet apart from a few
> lines that deal with input arguments and calling the appropriate
> underlying C++ code. Ideally it would be sensible to refactor the
> common python code into a new class (BaseContourSet?) and have
> relatively thin derived ContourSet and TriContourSet classes. But I'm
> not sure you'd like a relatively new mpl contributor to change such
> important code...
Ian,
As the person who fixed major bugs in cntr.c, you have wizard status, so 
go ahead! I have no objection to some refactoring, so long as 
everything works in the end, and is no more difficult to read and 
maintain than what is there now--which I am sure could be improved even 
without the Tri additions.
What sort of timeline do you have in mind?
One possibility would be to develop the tri* functionality at least 
initially as a module in lib/mpl_toolkits, like axes_grid and mplot3d; 
or in a module in lib/matplotlib. This could still take advantage of 
refactoring in contour.py. An advantage is that it would consolidate 
the triangle functionality so it would be easier to find, track, and 
document.
I copied this reply to the devel list--let's continue there as needed.
Eric
> 
> Ian

On Mon, Mar 15, 2010 at 12:37 PM, Ian Thomas <ian...@go...> wrote:
> Ben Axelrod <BAx...@co...> wrote:
>> I am a little unclear on what this is and what it is used for.
>
> It is used to generate contour plots for data that is defined on
> unstructured triangular grids. Currently mpl supports generating
> contour plots on regular rectangular grids; if you have an
> unstructured grid you have to interpolate it onto a regular grid
> before contouring it. Contouring directly from the triangular grid
> avoids the need for this interpolation.
Well then the meteorologist in me is an overwhelmingly +1 on having
such functionality available. Are you looking at making it possible to
construct a triangulation from the delaunay triangulation that is used
by griddata? (Sorry, I didn't follow the thread that closely.)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ian Thomas wrote:
> Alternatively, if you want to specify your own
> triangulation instead you can do that using a indices array of shape
> (3, ntri) where ntri is the number of triangles, and indices[:, i]
> defines the indices of the three points that the i-th triangle is
> composed of.
That would be better as (ntri, 3), to be compatible with the usual C 
ordering of numpy arrays.
just a nit,
- Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Ben Axelrod <BAx...@co...> wrote:
> I am a little unclear on what this is and what it is used for.
It is used to generate contour plots for data that is defined on
unstructured triangular grids. Currently mpl supports generating
contour plots on regular rectangular grids; if you have an
unstructured grid you have to interpolate it onto a regular grid
before contouring it. Contouring directly from the triangular grid
avoids the need for this interpolation.
> Is this to visualize the triangular grid for things like Finite Element Analysis (FEM) and Computational Fluid Dynamics (CFD)?
FEM and CFD are indeed big application areas for unstructured triangular grids.
> What kind of format is the data in?
At its simplest, assume you have n irregular spaced points defined by
x and y positions and you wish to contour some field z defined at
those points, where x, y and z are length n numpy arrays or lists.
You will use something like
 tricontour(x, y, z)
A default (Delaunay) triangulation will be constructed and contoured
for your pleasure. Alternatively, if you want to specify your own
triangulation instead you can do that using a indices array of shape
(3, ntri) where ntri is the number of triangles, and indices[:, i]
defines the indices of the three points that the i-th triangle is
composed of.
> Are there any standards for this type of thing?
I have no idea. I'm not proposing any file converters for/from any
standard file formats as all the information required for such a grid
is contained in the rather simple x, y and indices arrays.
> Do you have some example code or images?
My original posting of September last year includes source code,
examples and images. See
http://sourceforge.net/mailarchive/forum.php?thread_name=4AB3B95B.3090903%40noaa.gov&forum_name=matplotlib-users
This was packaged as a separate python module called 'mpl_tri' which
you can install and play with as much as you desire. I am now
proposing to integrate this into the core of matplotlib as I don't
wish to maintain it as a separate project. I've agreed to add a few
extras, as discussed in
http://sourceforge.net/mailarchive/forum.php?thread_name=hnbpkq%24o03%241%40dough.gmane.org&forum_name=matplotlib-users
Before going ahead with this I wished to ascertain how much interest
there was for this functionality as I don't want to spend time doing
something that isn't wanted or needed.
I hope that answers your questions,
Ian

Ben Axelrod wrote:
> I am a little unclear on what this is and what it is used for. Is
> this to visualize the triangular grid for things like Finite Element Analysis
> (FEM) and Computational Fluid Dynamics (CFD)?
In can be, yes -- though that's really only the part that renders the 
mesh. Contouring on a triangular mesh can be used to visualize data on 
such a mesh, as generated by FE or FV codes, but can also be used to 
contour and visualize data on any arbitrary points -- it's an 
alternative to interpolating to a regular grid before contouring.
Doing the contouring directly on a triangular mesh is more efficient and 
bit more robust, particularly near the bounds of the data.
> What kind of format is the data in?
It would take simple x,y,z vectors for the contouring routines. There is 
some discussion of the API in that thread. I'd like to see a standard 
class that holds a triangular mesh while we're at it -- to make it 
easier to separate the generation of the mesh from the use of the mesh.
 > Are there any standards for this type of thing?
I wish.
There is a netcdf standard for unstructured meshes being developed as we 
speak, primarily for oceanographic model, but that's all I know of -- 
and MPL doesn't (and shouldn't) support netcdf directly anyway.
There are common ways to express a triangular mesh -- ans we should use 
them:
ie. a NX3 array of indexes, where each row in the array is the three 
indexes into the point coordinate array.
some systems also store indexes to the neighbors of each triangle, etc. 
I think that should all be hidden in the mesh class.
 > Do you have some example code or images?
There were some links in that thread. Ian, maybe you should post them again.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I tried installing the two Mac OS X packages I found here. The .dmg file seems to have installed somewhere other than my EPD python path - doesn't seem to be in the Apple supplied Framework location either, so I'm sort of stumped on that one. The egg I tried to install with EPD's easy_install, and got the result below.
On a positive note, I seem to have been able to successfully compile matplotlib on RHEL (my deployment platform), so if I can get Mac (my development platform) figured out, I'll be golden!
>>sudo easy_install matplotlib-0.99.3rc1_r0-py2.6-macosx-10.6-universal.egg
Processing matplotlib-0.99.3rc1_r0-py2.6-macosx-10.6-universal.egg
creating /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib-0.99.3rc1_r0-py2.6-macosx-10.6-universal.egg
Extracting matplotlib-0.99.3rc1_r0-py2.6-macosx-10.6-universal.egg to /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages
Adding matplotlib 0.99.3rc1-r0 to easy-install.pth file
Installed /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib-0.99.3rc1_r0-py2.6-macosx-10.6-universal.egg
Processing dependencies for matplotlib==0.99.3rc1-r0
Searching for matplotlib==0.99.3rc1-r0
Reading http://pypi.python.org/simple/matplotlib/
Reading http://matplotlib.sourceforge.net
Reading http://sourceforge.net/project/showfiles.php?group_id=80706
Reading http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/
No local packages or download links found for matplotlib==0.99.3rc1-r0
error: Could not find suitable distribution for Requirement.parse('matplotlib==0.99.3rc1-r0')
 
On Mar 14, 2010, at 4:22 AM, Jouni K. Seppänen wrote:
> Jouni K. Seppänen <jk...@ik...> writes:
> 
>> Have you tried the instructions in release/osx/README? It seems that on
>> OS X it is easy to accidentally install a combination of libraries that
>> will cause build problems with matplotlib:
>> 
>> http://matplotlib.sourceforge.net/users/installing.html#build-osx
> 
> Also, it seems that John has uploaded a new release candidate at
> 
> http://drop.io/xortel1#
> 
> so you could try and see if it works for you. Please note that it's a
> release candidate, not a stable release.
> 
> -- 
> Jouni K. Seppänen
> http://www.iki.fi/jks
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I am a little unclear on what this is and what it is used for. Is this to visualize the triangular grid for things like Finite Element Analysis (FEM) and Computational Fluid Dynamics (CFD)? What kind of format is the data in? Are there any standards for this type of thing? Do you have some example code or images?
Thanks,
-Ben
 
-----Original Message-----
From: Ian Thomas [mailto:ian...@go...] 
Sent: Monday, March 15, 2010 7:01 AM
To: mat...@li...
Subject: [matplotlib-devel] Contouring unstructured triangular grids
Hello all,
I have some code to generate contour plots of unstructured triangular grids that I have volunteered to include in matplotlib. Some discussion of this has occurred in matplotlib-users, see
http://sourceforge.net/mailarchive/forum.php?thread_name=hnbpkq%24o03%241%40dough.gmane.org&forum_name=matplotlib-users
Before I go ahead, I want to check if others think this would be useful functionality to have in mpl or not.
Thanks,
Ian Thomas
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello all,
I have some code to generate contour plots of unstructured triangular
grids that I have volunteered to include in matplotlib. Some
discussion of this has occurred in matplotlib-users, see
http://sourceforge.net/mailarchive/forum.php?thread_name=hnbpkq%24o03%241%40dough.gmane.org&forum_name=matplotlib-users
Before I go ahead, I want to check if others think this would be
useful functionality to have in mpl or not.
Thanks,
Ian Thomas