matplotlib-devel Mailing List for matplotlib (Page 4)

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

Hi folks,
I use matplotlib all the time, and one of the features I particularly
like is the interactivity of its plot windows. I like being able to
zoom in to a rectangle. But there's one UI quirk that I find annoying,
and I wonder how difficult it would be to change. Often when I want to
zoom in, I want to change only (say) the upper x and y limits. So I
click at the top right corner I want and drag the mouse all the way
out of the axes, then release, and it zooms in to the right place. But
the UI is misleading: once the mouse leaves the axes, the box that
indicates where I'll be zooming too stops updating, often leaving it
quite far from the actual zoom region (i.e. in this case, not
extending all the way to the corner, even though the zoom will reach
all the way to the corner). The problem is worst when I (say) leave
the axes from the bottom, then reach over horizontally, so that the
last update doesn't represent the width at all.
Would it be possible to keep updating the zoom rectangle even when the
mouse has left the axes?
Thanks,
Anne

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

Thanks for the report.
A fix has been committed in r8191 (maint. branch) and r8292 (head).
Give it a try and let me know of any problems.
Regards,
-JJ
On Sat, Mar 13, 2010 at 4:49 PM, Ray Speth <sp...@mi...> wrote:
> Hello,
>
> I am encountering a problem with the legend entries for scatter plots when
> setting a figure DPI different from the default of 72. When the DPI is
> higher than 72, the markers in the legend become disproportionately large
> and get scrunched together. It looks like what is happening is the marker
> size is being transformed twice, and the offsets are not being transformed
> at all.
>
> I have tried to debug it, and it looks like the problem is the way that the
> DrawingArea that contains the legend interacts with the Collection object.
> To fix the spacing, the _transOffset property of the Collection needs to be
> set, but the transform being applied by the DrawingArea ends up scaling the
> marker size instead.
>
> I have attached a sample script which shows the problem. I am using the
> current development version of matplotlib checked out from git, with Python
> 2.6.2. The issue also exists in version 0.99.1.
>
> Thanks,
> Ray Speth
>
> ------------------------------------------------------------------------------
> 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
>
>

Hello,
I am encountering a problem with the legend entries for scatter plots 
when setting a figure DPI different from the default of 72. When the DPI 
is higher than 72, the markers in the legend become disproportionately 
large and get scrunched together. It looks like what is happening is the 
marker size is being transformed twice, and the offsets are not being 
transformed at all.
I have tried to debug it, and it looks like the problem is the way that 
the DrawingArea that contains the legend interacts with the Collection 
object. To fix the spacing, the _transOffset property of the Collection 
needs to be set, but the transform being applied by the DrawingArea ends 
up scaling the marker size instead.
I have attached a sample script which shows the problem. I am using the 
current development version of matplotlib checked out from git, with 
Python 2.6.2. The issue also exists in version 0.99.1.
Thanks,
Ray Speth

Sorry for the confusion - I meant to say that *if* the other bug only
occurs in some newer versions, you could try the patch. But if I
understand your message correctly, it seems that you can't compile
matplotlib on OS X at all, so the patch is not useful for you.
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
Jouni
Michael Hearne <mh...@us...> writes:
> Jouni - When you say that the FreeType issue is caused by changes in "newer" versions of matplotlib, are those versions more recent than revision 7900, or before?
>
> I assumed "more recent", and so I checked out revision 7901, edited make.osx to point PREFIX to a local directory, renamed it to "Makefile", and ran setup.py build and install. The resulting ftfont.so file still has the "_FT_Attach_File" symbol undefined, and I get the same error as in my bug report.
>
> How old a revision do I need in order to avoid the FreeType issue?
>
> Incidentally, I'm seeing the same FreeType issue on RedHat Linux. Is everybody experiencing this bug, or is it perhaps related to EPD (the Python on both my Mac and RHEL boxes).
>
> --Mike 
> On Mar 11, 2010, at 1:24 PM, Jouni K. Seppänen wrote:
>
>> Michael Hearne <mh...@us...> writes:
>> 
>>> 2) Patch my current code with the fix already in SVN. I would need
>>> someone to point me to the relevant files, and give me some pointers
>>> on applying the patch.
>> 
>> The bug was fixed in revision 7900, and revision 7899 introduced a check
>> in the pdf backend that raises an exception instead of outputting
>> invalid pdf. If you can build some old revisions (and your FreeType issue
>> is caused by some newer changes in matplotlib) you could apply just
>> these changes to a buildable revision and see if it works.
>> 
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Jouni - When you say that the FreeType issue is caused by changes in "newer" versions of matplotlib, are those versions more recent than revision 7900, or before?
I assumed "more recent", and so I checked out revision 7901, edited make.osx to point PREFIX to a local directory, renamed it to "Makefile", and ran setup.py build and install. The resulting ftfont.so file still has the "_FT_Attach_File" symbol undefined, and I get the same error as in my bug report.
How old a revision do I need in order to avoid the FreeType issue?
Incidentally, I'm seeing the same FreeType issue on RedHat Linux. Is everybody experiencing this bug, or is it perhaps related to EPD (the Python on both my Mac and RHEL boxes).
--Mike 
On Mar 11, 2010, at 1:24 PM, Jouni K. Seppänen wrote:
> Michael Hearne <mh...@us...> writes:
> 
>> 2) Patch my current code with the fix already in SVN. I would need
>> someone to point me to the relevant files, and give me some pointers
>> on applying the patch.
> 
> The bug was fixed in revision 7900, and revision 7899 introduced a check
> in the pdf backend that raises an exception instead of outputting
> invalid pdf. If you can build some old revisions (and your FreeType issue
> is caused by some newer changes in matplotlib) you could apply just
> these changes to a buildable revision and see if it works.
> 
> Index: src/path_converters.h
> ===================================================================
> --- src/path_converters.h	(revision 7898)
> +++ src/path_converters.h	(revision 7900)
> @@ -684,9 +684,15 @@
> {
> if (m_origdNorm2 != 0.0)
> {
> - queue_push(agg::path_cmd_line_to, m_nextX, m_nextY);
> + queue_push((m_moveto || m_after_moveto) ?
> + agg::path_cmd_move_to : agg::path_cmd_line_to,
> + m_nextX, m_nextY);
> + m_moveto = false;
> }
> - queue_push(agg::path_cmd_line_to, m_lastx, m_lasty);
> + queue_push((m_moveto || m_after_moveto) ?
> + agg::path_cmd_move_to : agg::path_cmd_line_to,
> + m_lastx, m_lasty);
> + m_moveto = false;
> queue_push(agg::path_cmd_stop, 0.0, 0.0);
> }
> 
> Index: lib/matplotlib/tests/test_simplification.py
> ===================================================================
> --- lib/matplotlib/tests/test_simplification.py	(revision 7898)
> +++ lib/matplotlib/tests/test_simplification.py	(revision 7900)
> @@ -2,11 +2,10 @@
> import matplotlib
> from matplotlib.testing.decorators import image_comparison, knownfailureif
> import matplotlib.pyplot as plt
> -from matplotlib import patches, path
> 
> from pylab import *
> import numpy as np
> -from matplotlib import patches, path
> +from matplotlib import patches, path, transforms
> nan = np.nan
> Path = path.Path
> 
> @@ -134,6 +133,38 @@
> 
> assert len(simplified) == 13
> 
> +def test_start_with_moveto():
> + # Should be entirely clipped away to a single MOVETO
> + data = """
> +ZwAAAAku+v9UAQAA+Tj6/z8CAADpQ/r/KAMAANlO+v8QBAAAyVn6//UEAAC6ZPr/2gUAAKpv+v+8
> +BgAAm3r6/50HAACLhfr/ewgAAHyQ+v9ZCQAAbZv6/zQKAABepvr/DgsAAE+x+v/lCwAAQLz6/7wM
> +AAAxx/r/kA0AACPS+v9jDgAAFN36/zQPAAAF6Pr/AxAAAPfy+v/QEAAA6f36/5wRAADbCPv/ZhIA
> +AMwT+/8uEwAAvh77//UTAACwKfv/uRQAAKM0+/98FQAAlT/7/z0WAACHSvv//RYAAHlV+/+7FwAA
> +bGD7/3cYAABea/v/MRkAAFF2+//pGQAARIH7/6AaAAA3jPv/VRsAACmX+/8JHAAAHKL7/7ocAAAP
> +rfv/ah0AAAO4+/8YHgAA9sL7/8QeAADpzfv/bx8AANzY+/8YIAAA0OP7/78gAADD7vv/ZCEAALf5
> ++/8IIgAAqwT8/6kiAACeD/z/SiMAAJIa/P/oIwAAhiX8/4QkAAB6MPz/HyUAAG47/P+4JQAAYkb8
> +/1AmAABWUfz/5SYAAEpc/P95JwAAPmf8/wsoAAAzcvz/nCgAACd9/P8qKQAAHIj8/7cpAAAQk/z/
> +QyoAAAWe/P/MKgAA+aj8/1QrAADus/z/2isAAOO+/P9eLAAA2Mn8/+AsAADM1Pz/YS0AAMHf/P/g
> +LQAAtur8/10uAACr9fz/2C4AAKEA/f9SLwAAlgv9/8ovAACLFv3/QDAAAIAh/f+1MAAAdSz9/ycx
> +AABrN/3/mDEAAGBC/f8IMgAAVk39/3UyAABLWP3/4TIAAEFj/f9LMwAANm79/7MzAAAsef3/GjQA
> +ACKE/f9+NAAAF4/9/+E0AAANmv3/QzUAAAOl/f+iNQAA+a/9/wA2AADvuv3/XDYAAOXF/f+2NgAA
> +29D9/w83AADR2/3/ZjcAAMfm/f+7NwAAvfH9/w44AACz/P3/XzgAAKkH/v+vOAAAnxL+//04AACW
> +Hf7/SjkAAIwo/v+UOQAAgjP+/905AAB5Pv7/JDoAAG9J/v9pOgAAZVT+/606AABcX/7/7zoAAFJq
> +/v8vOwAASXX+/207AAA/gP7/qjsAADaL/v/lOwAALZb+/x48AAAjof7/VTwAABqs/v+LPAAAELf+
> +/788AAAHwv7/8TwAAP7M/v8hPQAA9df+/1A9AADr4v7/fT0AAOLt/v+oPQAA2fj+/9E9AADQA///
> ++T0AAMYO//8fPgAAvRn//0M+AAC0JP//ZT4AAKsv//+GPgAAojr//6U+AACZRf//wj4AAJBQ///d
> +PgAAh1v///c+AAB+Zv//Dz8AAHRx//8lPwAAa3z//zk/AABih///TD8AAFmS//9dPwAAUJ3//2w/
> +AABHqP//ej8AAD6z//+FPwAANb7//48/AAAsyf//lz8AACPU//+ePwAAGt///6M/AAAR6v//pj8A
> +AAj1//+nPwAA/////w=="""
> +
> + verts = np.fromstring(data.decode('base64'), dtype='<i4')
> + verts = verts.reshape((len(verts) / 2, 2))
> + path = Path(verts)
> + segs = path.iter_segments(transforms.IdentityTransform, clip=(0.0, 0.0, 100.0, 100.0))
> + segs = list(segs)
> + assert len(segs) == 1
> + assert segs[0][1] == Path.MOVETO
> +
> if __name__=='__main__':
> import nose
> nose.runmodule(argv=['-s','--with-doctest'], exit=False)
> Index: lib/matplotlib/path.py
> ===================================================================
> --- lib/matplotlib/path.py	(revision 7898)
> +++ lib/matplotlib/path.py	(revision 7900)
> @@ -115,6 +115,8 @@
> codes = np.asarray(codes, self.code_type)
> assert codes.ndim == 1
> assert len(codes) == len(vertices)
> + if len(codes):
> + assert codes[0] == self.MOVETO
> 
> assert vertices.ndim == 2
> assert vertices.shape[1] == 2
> Index: lib/matplotlib/backends/backend_pdf.py
> ===================================================================
> --- lib/matplotlib/backends/backend_pdf.py	(revision 7898)
> +++ lib/matplotlib/backends/backend_pdf.py	(revision 7900)
> @@ -1206,8 +1206,12 @@
> last_points = None
> for points, code in path.iter_segments(transform, clip=clip):
> if code == Path.MOVETO:
> + # This is allowed anywhere in the path
> cmds.extend(points)
> cmds.append(Op.moveto)
> + elif last_points is None:
> + # The other operations require a previous point
> + raise ValueError, 'Path lacks initial MOVETO'
> elif code == Path.LINETO:
> cmds.extend(points)
> cmds.append(Op.lineto)
> 
> -- 
> 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

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I get inconsistent behavior when plotting multiple sets of data with plt.hist. Here's a quick example:
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>> x = np.random.randn(10)
>>> y = np.random.randn(9)
>>> plt.hist([x, y])
The above code plots two sets of histograms, as expected. My data sets have different lengths, but by coincidence, I had two data sets with the same length. When you call hist on data sets with the same length
>>> plt.hist([x[:-1], y])
then hist actually transposes the data; for the above, you get 9 sets of data instead of two.
Below is a patch that fixes the issue, but unfortunately, it'll probably break other peoples' code; in fact, it breaks the example code (histogram_demo_extended.py). I'm not sure what's worse: dealing with the inconsistency or breaking a lot of code. But if there's a time to break code, MPL 1.0 might be it :)
Best,
-Tony
Index: lib/matplotlib/axes.py
===================================================================
--- lib/matplotlib/axes.py	(revision 8187)
+++ lib/matplotlib/axes.py	(working copy)
@@ -7122,7 +7122,7 @@
 
 try:
 # make sure a copy is created: don't use asarray
- x = np.transpose(np.array(x))
+ x = np.array(x)
 if len(x.shape)==1:
 x.shape = (1,x.shape[0])
 elif len(x.shape)==2 and x.shape[1]<x.shape[0]:

Michael Droettboom wrote:
> Is this bug related to matplotlib? (i.e. does it happen only when 
> matplotlib is imported?)
It looks like you've done a pure-wx test, so it is a wx issue.
> If not, you may have more luck on the wxpython 
> mailing list.
yup, that's the place for it -- I suspect that windows server 2003 is 
old enough that it may not have the newer alpha-supporting drawing stuff 
-- that may be a dll that you could add, though.
You'll get a better answer on the wxpython-users list.
-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...

Is this bug related to matplotlib? (i.e. does it happen only when 
matplotlib is imported?) If not, you may have more luck on the wxpython 
mailing list.
Mike
MOhanKumar wrote:
> wx.AlphaPixelData() is failing on windows server 2003. The sample code is
> given below.
> The same is working fine on windows xp. what could be the reason?
>
> import wx
>
> class Size(wx.Frame):
> def __init__(self, parent, id, title):
> wx.Frame.__init__(self, parent, id, title, size=(250, 200))
> absFilename =
> "C:\Python26\Lib\site-packages\win32\Demos\images\smiley.bmp"
> bmp = wx.Bitmap(absFilename, wx.BITMAP_TYPE_BMP)
> pixelData = wx.AlphaPixelData(bmp)
>
> if not pixelData:
> print "error"
> else:
> print "fine"
>
>
>
> app = wx.App(False)
> Size(None, -1, 'Test')
> app.MainLoop()
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

wx.AlphaPixelData() is failing on windows server 2003. The sample code is
given below.
The same is working fine on windows xp. what could be the reason?
import wx
class Size(wx.Frame):
 def __init__(self, parent, id, title):
 wx.Frame.__init__(self, parent, id, title, size=(250, 200))
 absFilename =
"C:\Python26\Lib\site-packages\win32\Demos\images\smiley.bmp"
 bmp = wx.Bitmap(absFilename, wx.BITMAP_TYPE_BMP)
 pixelData = wx.AlphaPixelData(bmp)
 if not pixelData:
 print "error"
 else:
 print "fine"
app = wx.App(False)
Size(None, -1, 'Test')
app.MainLoop()
-- 
View this message in context: http://old.nabble.com/wx.AlphaPixelData%28%29-is-failing-on-windows-server-2003-tp27847892p27847892.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.