matplotlib-devel Mailing List for matplotlib (Page 3)

In mpl_toolkits.mplot3d, I noticed that if I want to add text in the
Axes3D, I need to use Axes3D.text3D . However, that method doesn't
pass in kwargs to set the text properties onto the Axes.text method.
Hence, I made this simple modification that passes kwargs on text3D on
to text so that the properties are properly applied. Attached is the
diff against an up-to-date svn...
This has also been submitted as sourceforge bug ID 2972928

On Thu, Mar 18, 2010 at 7:46 PM, Fernando Perez <fpe...@gm...> wrote:
> On Thu, Mar 18, 2010 at 3:49 PM, Christopher Barker
> <Chr...@no...> wrote:
>>
>>
>> Good solution, and thanks for working on this!
>
> Thanks.
>
> I have one more question on this feature. I personally think that
> this should be the way to use mpl in general when scripting, and the
> way I want to teach, because it's easy and short while encouraging
> access to more robust patterns (figure/axes handing instead of the
> stateful pyplot). For this reason, I think the name should be really
> well chosen, and I'm not convinced fig_subplot is a very good one.
>
> I know naming discussions can be annoying, but if this ends up being
> the most popular/common entry point for making plots, it may be worth
> spending a moment on picking it right. Ideas (I'm *awful* at naming)?
>
> - plot_array?
> - plots?
> - subplots?
> - parray?
> - plotarr?
>
> - something actually good from someone else?
>
> I'll finish the patch tonight, we can always fix the name later as
> it's a trivial search/replace on fig_subplots -> new_great_name.
I also think the name should be changed, and there should be an entry
in the matplotlib.figure.Figure API. One additional suggestion is
"subarray" and matplotlib.pyplot.subarray would be a thin wrapper to
matplotlib.figure.Figure.add_subarray. The former would return (fig,
axarray) using gcf() to get the current figure, and the latter would
simply create the subarray and return it. The would break a bit with
the pyplot "axes" and "subplot" commands that only return the Axes and
Subplot instances (and not the implicit Figure instance created/used)
but I can live with that because part of the goal here is to give easy
access to axes and figure creation so the user can get in the habit of
using the API directly for most things.
As for the other name suggestions, I like "subplots".
JDH

On Thu, Mar 18, 2010 at 3:49 PM, Christopher Barker
<Chr...@no...> wrote:
>
>
> Good solution, and thanks for working on this!
Thanks.
I have one more question on this feature. I personally think that
this should be the way to use mpl in general when scripting, and the
way I want to teach, because it's easy and short while encouraging
access to more robust patterns (figure/axes handing instead of the
stateful pyplot). For this reason, I think the name should be really
well chosen, and I'm not convinced fig_subplot is a very good one.
I know naming discussions can be annoying, but if this ends up being
the most popular/common entry point for making plots, it may be worth
spending a moment on picking it right. Ideas (I'm *awful* at naming)?
- plot_array?
- plots?
- subplots?
- parray?
- plotarr?
- something actually good from someone else?
I'll finish the patch tonight, we can always fix the name later as
it's a trivial search/replace on fig_subplots -> new_great_name.
Cheers,
f

I've observed a significant difference in the time required by different
plotting functions. With a plot of 5000 random data points (all
positive, non-zero), plt.semilogx takes 3.5 times as long as plt.plot.
(Data for the case of saving to PDF, ratio changes to about 3.1 for PNG
on my machine.)
I used cProfile (script attached) and found several significant
differences between the profiles of each plotting command. On my first
analysis, it appears that most of the difference is due to increased use
of mathtext in semilogx:
 ==================================
 Plotting command
==================================================================
cumtime (s) plot semilogx semilogy loglog
==================================================================
total running time 0.618 2.192 0.953 1.362
axis.py:181(draw) 0.118 1.500 0.412 0.569
text.py:504(draw) 0.056 1.353 0.290 0.287
mathtext.py:2765(__init__) 0.000 1.018 0.104 0.103
mathtext.py:2772(parse) --- 1.294 0.143 0.254
pyparsing.py:1018(parseString) --- 0.215 0.216 0.221
pyparsing.py:3129(oneOf) --- 0.991 --- ---
pyparsing.py:3147(<lambda>) --- 0.358 --- ---
lines.py:918(_draw_solid) 0.243 0.358 0.234 0.352
=================================================================
It seems that semilogx could be made as fast as semilogy since they have
to do the same amount of work, but I'm not sure where the differences
lie. Can anyone suggest where I should look first?
Much thanks,
Andrew Hawryluk
matplotlib.__version__ = '0.99.1'
Windows XP Professional
Version 2002, Service Pack 3
Intel Pentium 4 CPU 3.00 GHz, 2.99 GHz, 0.99 GB of RAM

Fernando Perez wrote:
> Based on the feedback, I'll finish it tonight with squeeze=True as a
> kwarg, that behaves:
> 
> - if True (default): single axis is returned as a scalar, Nx1 or 1xN
> are returned as numpy 1-d arrays, and only NxM with N>1 and M>1 are
> returned as a 2d array.
> 
> - if False, no squeezing at all is done, the return value is always a
> 2-d array, even if it ends up being 1x1.
Good solution, and thanks for working on this!
-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 Thu, Mar 18, 2010 at 11:47 AM, John Hunter <jd...@gm...> wrote:
> I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is
> natural. This is also the most common use case so the most important
> to get right. If you aren't doing multiple subplots, a plain ol
> subplot(111) may be preferred to fig_subplots anyhow.
>
I agree with John that for nx1 or 1xn, 1-d indexing seems more
natural, and is the more pythonic solution given how numpy doesn't
distinguish between row and column arrays when they are 1-d, in
contrast to matlab. This is why I went for the approach above.
Based on the feedback, I'll finish it tonight with squeeze=True as a
kwarg, that behaves:
- if True (default): single axis is returned as a scalar, Nx1 or 1xN
are returned as numpy 1-d arrays, and only NxM with N>1 and M>1 are
returned as a 2d array.
- if False, no squeezing at all is done, the return value is always a
2-d array, even if it ends up being 1x1.
I think this gives a very convenient interactive/lightweight scripting
interface, while letting application builders who may need to write
generic code that is dimension agnostic have robust code that needs no
special-casing by passing squeeze=False.
Unless I hear otherwise, I'll make the commit with these changes
(updating the docstring and example script accordingly).
Cheers,
f

Attached and also pasted below is an example which creates a 3d figure
using polar coordinates rather than the x and y. The solution was
created by Armin Moser when I posted a question to the users list.
There are currently no examples of polar coordinates in 3D available.
Any objections to adding this to mpl_examples/mplot3d?
Thanks,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://www.hep.wisc.edu/~jklukas/
----------------------------------------
import matplotlib.pyplot as plt
import numpy as np
from mpl_toolkits.mplot3d import Axes3D
from matplotlib import cm
fig = plt.figure()
ax = Axes3D(fig)
# create supporting points in polar coordinates
r = np.linspace(0, 1.25, 50)
phi = np.linspace(0, 2*np.pi, 50)
R, PHI = np.meshgrid(r,phi)
# transform them to cartesian system
X,Y = R * np.cos(PHI), R * np.sin(PHI)
Z = ((R**2 - 1)**2)
ax.plot_surface(X, Y, Z, rstride=1, cstride=1, cmap=cm.jet)
ax.set_zlim3d(0, 1)
ax.set_xlabel(r'$\phi_\mathrm{real}$')
ax.set_ylabel(r'$\phi_\mathrm{im}$')
ax.set_zlabel(r'$V(\phi)$')
ax.set_xticks([])
plt.show()
----------------------------------------

I have implemented breakx and breaky methods for the Axes class and
attached the diff for axes.py to this message.
You can test out the function with the following examples:
------------------
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt
# Broken y
fig = plt.figure()
main_axes = plt.axes()
plt.title('Broken x-axis example')
plt.xlabel('x-axis label')
subaxes = main_axes.breaky([0., 1.9, 5.1, 6.9, 9.1, 12])
for axes in subaxes:
 axes.plot(np.linspace(0,12,13),np.linspace(0,12,13))
plt.ylabel('y-axis label')
plt.show()
------------------
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt
# Broken x
fig = plt.figure()
main_axes = plt.axes()
plt.title('Broken x-axis example')
plt.ylabel('y-axis label')
subaxes = main_axes.breakx([0., 1.9, 5.1, 6.9, 9.1, 12])
for axes in subaxes:
 axes.plot(np.linspace(0,12,13),np.linspace(0,12,13))
plt.xlabel('x-axis label')
plt.show()
---------------------
I've included in the docstrings some of the TODO items, but this is
pretty stable in its current form.
Cheers,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://www.hep.wisc.edu/~jklukas/
On Tue, Mar 16, 2010 at 1:08 PM, Jeff Klukas <kl...@wi...> wrote:
>> 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.
>
> I can try to do this. I think I would prefer, however, not to resize
> the "self" axes and continue with my current approach of creating two
> new axes within the original axes. On the user end, I think it makes
> more sense to set the title and ylabel of the main axes, rather than
> setting them for the individual upper and lower axes. More on that
> below.
>
>>> 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?
>>
>> klukas, I'm afraid I don't understand your issue... Can you explain using it differently?
>
> In my approach, you end up with a main axes object that is invisible,
> and then two visible axes objects (upper and lower) within the main
> axes. I would ideally like to have the y label display in the middle
> of the main y-axis, independent of where the break lies. If I place a
> y label on the main axes (which has ticks or tick labels), though, it
> appears right up against the axis line. I'd like it to be placed
> further to the left, clear of the tick labels that appear on the upper
> and lower axes. So, I'd like to be able to access whatever algorithm
> is used to choose the offset of the axis label, and explicitly set the
> offset of the ylabel for the main axes so that it clears the tick
> labels.
>
> // Jeff
>

On Thu, Mar 18, 2010 at 2:24 PM, Christopher Barker
<Chr...@no...> wrote:
> John Hunter wrote:
>>> I think the only two options should be scalar or 2-d array, it seems a
>>> bit much to have a 1-d array option as well.
>>
>> I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is
>> natural. This is also the most common use case so the most important
>> to get right.
>
> OK, but then how do you handle the fact that you might get a 0-d, 1-d or
> 2-d result? Eric's "squeeze" flag would result in that. Having squeeze1d
> and squeeze2d flags seems a bit much.
squeeze configured with a kwarg seems like a good compromise. As long
as the behavior is well documented it shouldn't pose any problems.
And we still have access to fig.axes in the same format is has always
been in.
JDH

John Hunter wrote:
>> I think the only two options should be scalar or 2-d array, it seems a
>> bit much to have a 1-d array option as well.
> 
> I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is
> natural. This is also the most common use case so the most important
> to get right.
OK, but then how do you handle the fact that you might get a 0-d, 1-d or 
2-d result? Eric's "squeeze" flag would result in that. Having squeeze1d 
and squeeze2d flags seems a bit much.
-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 Thu, Mar 18, 2010 at 1:38 PM, Christopher Barker
<Chr...@no...> wrote:
> I think the only two options should be scalar or 2-d array, it seems a
> bit much to have a 1-d array option as well.
I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is
natural. This is also the most common use case so the most important
to get right. If you aren't doing multiple subplots, a plain ol
subplot(111) may be preferred to fig_subplots anyhow.
JDH

Fernando Perez wrote:
> While chatting today with John, he suggested that a better api for
> this would be to return an *array* of supblots, so that one could
> index them with a[i,j] for the plot in row i, column j.
That would be nice.
> implemented this already, but before committing it, I have one doubt:
> what to do when nrows==ncols==1, the single subplot case? I'm inclined
> to return only the subplot instead of a one-element array, so that one
> can say
> 
> f, a = fig_subplot()
> a.plot(...)
> 
> instead of having to do
> 
> f, a = fig_subplot()
> a[0].plot(...)
> But this means the return value of the function would be:
> - fig, axis if nr=nc=1
> - fig, axis_array in all other cases.
actually, wouldn't there be three options, essentially:
scalar, 1-d, 2-d
so the second example might be.
f, a = fig_subplot()
a[0,0].plot(...)
Eric Firing wrote:
> The behavior one wants depends on whether one is calling fig_subplot in 
> a program in which the number of subplots could range from 0 to n, or 
> whether the call is being made with the number of subplots hardwired.
good point.
> The latter may be most common, but the former seems like an important 
> use case. I suggest providing a kwarg, e.g. "squeeze=True" as the 
> default, to eliminate zero-size-dimensions from the array, and False for 
> the case where nrows and/or ncols could be zero but one wants to be able 
> to iterate over the resulting array regardless.
this feels a bit ugly to me as well, though not too bad.
Maybe this is too much magic, but could you look at what was passed in 
to the subplot call:
I don't remember if you are following the figure.add_subplot() api, but:
If nothing, then the user is clearly asking for a single axis.
if (r,c,n) then the user is specifying a 2-d arrangement, even if r and 
c happen to be 1.
I think the only two options should be scalar or 2-d array, it seems a 
bit much to have a 1-d array option as well.
Also, IIUC correctly, Figure.add_subplot always returns a SINGLE axis -- 
you have to call it multiple times to get the whole set. Does this 
version return the whole set?
-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 Thu, Mar 18, 2010 at 12:20 PM, Eric Firing <ef...@ha...> wrote:
> Fernando Perez wrote:
>> While chatting today with John, he suggested that a better api for
>> this would be to return an *array* of supblots, so that one could
>> index them with a[i,j] for the plot in row i, column j. I've
>> implemented this already, but before committing it, I have one doubt:
>> what to do when nrows==ncols==1, the single subplot case? I'm inclined
>> to return only the subplot instead of a one-element array, so that one
>> can say
>>
>> f, a = fig_subplot()
>> a.plot(...)
>>
>> instead of having to do
>>
>> f, a = fig_subplot()
>> a[0].plot(...)
>>
>> But this means the return value of the function would be:
>> - fig, axis if nr=nc=1
>> - fig, axis_array in all other cases.
>
> The behavior one wants depends on whether one is calling fig_subplot in
> a program in which the number of subplots could range from 0 to n, or
> whether the call is being made with the number of subplots hardwired.
> The latter may be most common, but the former seems like an important
> use case. I suggest providing a kwarg, e.g. "squeeze=True" as the
> default, to eliminate zero-size-dimensions from the array, and False for
> the case where nrows and/or ncols could be zero but one wants to be able
> to iterate over the resulting array regardless.
+1 This feels like a clean solution to the problem.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Jed Frechette wrote:
> I made a one line change to matplotlib.axis.Axis.draw (attached) that 
> simply reverses the order that ticks are plotted in.
Argh, I knew that was to easy. This is only a partial fix because the 
horizontal minor grid still gets drawn above the vertical major grid.
--
Jed Frechette
Lidar Guys
Mobile: 505-280-1340

Fernando Perez wrote:
> Howdy,
> 
> On Wed, Feb 24, 2010 at 11:27 AM, Fernando Perez <fpe...@gm...> wrote:
>> OK, since I know people are busy, I took silence as acquiescence.
>> Committed in r8151, please let me know if I messed anything up and
>> I'll try to fix it. I'm used to the numpy docstring standard, but I
>> tried to adapt it to the mpl one by looking at the rest of pyplot,
>> let me know if it needs fine-tuning.
> 
> While chatting today with John, he suggested that a better api for
> this would be to return an *array* of supblots, so that one could
> index them with a[i,j] for the plot in row i, column j. I've
> implemented this already, but before committing it, I have one doubt:
> what to do when nrows==ncols==1, the single subplot case? I'm inclined
> to return only the subplot instead of a one-element array, so that one
> can say
> 
> f, a = fig_subplot()
> a.plot(...)
> 
> instead of having to do
> 
> f, a = fig_subplot()
> a[0].plot(...)
> 
> But this means the return value of the function would be:
> - fig, axis if nr=nc=1
> - fig, axis_array in all other cases.
The behavior one wants depends on whether one is calling fig_subplot in 
a program in which the number of subplots could range from 0 to n, or 
whether the call is being made with the number of subplots hardwired. 
The latter may be most common, but the former seems like an important 
use case. I suggest providing a kwarg, e.g. "squeeze=True" as the 
default, to eliminate zero-size-dimensions from the array, and False for 
the case where nrows and/or ncols could be zero but one wants to be able 
to iterate over the resulting array regardless.
Eric
> 
> so it's a bit ugly. I think this is a case where practicality beats
> purity and my nose tells me to go for the less pretty but more
> convenient api, but I'm happy to get feedback. The return code reads
> currently:
> 
> # Reshape the array to have the final desired dimension (nrow,ncol), though
> # discarding unneeded dimensions that equal 1. If we only have one
> # subplot, just return it instead of a 1-element array.
> if nplots==1:
> return fig, axarr[0]
> else:
> return fig, axarr.reshape(nrows, ncols).squeeze()
> 
> 
> Once we settle this design decision, I'll update the docstring and
> example and will post the patch for final review before committing.
> 
> Cheers,
> 
> f
> 
> ------------------------------------------------------------------------------
> 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

Howdy,
On Wed, Feb 24, 2010 at 11:27 AM, Fernando Perez <fpe...@gm...> wrote:
> OK, since I know people are busy, I took silence as acquiescence.
> Committed in r8151, please let me know if I messed anything up and
> I'll try to fix it. I'm used to the numpy docstring standard, but I
> tried to adapt it to the mpl one by looking at the rest of pyplot,
> let me know if it needs fine-tuning.
While chatting today with John, he suggested that a better api for
this would be to return an *array* of supblots, so that one could
index them with a[i,j] for the plot in row i, column j. I've
implemented this already, but before committing it, I have one doubt:
what to do when nrows==ncols==1, the single subplot case? I'm inclined
to return only the subplot instead of a one-element array, so that one
can say
f, a = fig_subplot()
a.plot(...)
instead of having to do
f, a = fig_subplot()
a[0].plot(...)
But this means the return value of the function would be:
- fig, axis if nr=nc=1
- fig, axis_array in all other cases.
so it's a bit ugly. I think this is a case where practicality beats
purity and my nose tells me to go for the less pretty but more
convenient api, but I'm happy to get feedback. The return code reads
currently:
 # Reshape the array to have the final desired dimension (nrow,ncol), though
 # discarding unneeded dimensions that equal 1. If we only have one
 # subplot, just return it instead of a 1-element array.
 if nplots==1:
 return fig, axarr[0]
 else:
 return fig, axarr.reshape(nrows, ncols).squeeze()
Once we settle this design decision, I'll update the docstring and
example and will post the patch for final review before committing.
Cheers,
f

With the current release 0.99.1 minor grid lines get drawn above major 
grid lines. This makes it impossible, for example, to have a dark gray 
major grid and a light gray minor grid because the minor grid will 
overwrite the major grid. I'm assuming this is a bug but maybe there is a 
design reason for this?
As far as I can tell this behaviour comes down to 
matplotlib.axis.Axis.iter_ticks returning the major ticks before the minor 
ticks. I made a one line change to matplotlib.axis.Axis.draw (attached) 
that simply reverses the order that ticks are plotted in.
I will admit though that I don't follow Matplotlib development closely and 
only tested the fix on the released version so if this has already been 
fixed or there are unintended consequences I'm not aware of please ignore 
the noise.
Thanks,
-- 
Jed Frechette
Lidar Guys
Mobile: 505-280-1340

Sandro Tosi wrote:
> forwarded 573179 mat...@li...
> thanks
> 
> Hello Matplotlib developers,
> I'm forwarding this bug a Debian user reported some days ago. It would
> be nice it you could give it a look
Using svn trunk mpl and numpy 1.5.0.dev8042, I can't reproduce it; I get 
a blank figure and a blank colorbar, with no exception. I suspect the 
difference is in numpy.ma, not matplotlib.
Eric
> 
> Thanks in advance,
> Sandro
> 
> On Tue, Mar 9, 2010 at 17:05, Yaroslav Halchenko <de...@on...> wrote:
>> Package: python-matplotlib
>> Version: 0.99.1.2-3
>> Severity: normal
>>
>>
>> throws an exception while comparing two masked arrays which have no values (all
>> masked out)... sure thing it can't determine vmin/vmax to be used (unless clim
>> is used explicitely), but the exception which is thrown is non-informative. I
>> thought that upstream might want to make it more user-friendly -- please
>> forward upstream.
>>
>> Here is the code to reproduce:
>> import pylab as pl
>> import numpy as np
>>
>> size = (5, 5)
>> d = np.ones(size)
>> mask = d.astype(bool)
>>
>> md = np.ma.masked_array(d, mask)
>> pl.imshow(md)
>> # explicit clim would eliminate the problem
>> #pl.clim(0, 1)
>> pl.colorbar()
>>
>> and here is the traceback:
>>
>> Traceback (most recent call last):
>> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1417, in __call__
>> return self.func(*args)
>> File "/usr/lib/pymodules/python2.5/matplotlib/backends/backend_tkagg.py", line 212, in resize
>> self.show()
>> File "/usr/lib/pymodules/python2.5/matplotlib/backends/backend_tkagg.py", line 215, in draw
>> FigureCanvasAgg.draw(self)
>> File "/usr/lib/pymodules/python2.5/matplotlib/backends/backend_agg.py", line 314, in draw
>> self.figure.draw(self.renderer)
>> File "/usr/lib/pymodules/python2.5/matplotlib/artist.py", line 46, in draw_wrapper
>> draw(artist, renderer, *kl)
>> File "/usr/lib/pymodules/python2.5/matplotlib/figure.py", line 773, in draw
>> for a in self.axes: a.draw(renderer)
>> File "/usr/lib/pymodules/python2.5/matplotlib/artist.py", line 46, in draw_wrapper
>> draw(artist, renderer, *kl)
>> File "/usr/lib/pymodules/python2.5/matplotlib/axes.py", line 1701, in draw
>> im.draw(renderer)
>> File "/usr/lib/pymodules/python2.5/matplotlib/artist.py", line 46, in draw_wrapper
>> draw(artist, renderer, *kl)
>> File "/usr/lib/pymodules/python2.5/matplotlib/image.py", line 237, in draw
>> im = self.make_image(renderer.get_image_magnification())
>> File "/usr/lib/pymodules/python2.5/matplotlib/image.py", line 182, in make_image
>> x = self.to_rgba(self._A, self._alpha)
>> File "/usr/lib/pymodules/python2.5/matplotlib/cm.py", line 166, in to_rgba
>> x = self.norm(x)
>> File "/usr/lib/pymodules/python2.5/matplotlib/colors.py", line 763, in __call__
>> elif vmin==vmax:
>> File "/usr/lib/python2.5/site-packages/numpy/ma/core.py", line 3119, in __eq__
>> check._mask = mask
>> AttributeError: 'numpy.bool_' object has no attribute '_mask'
>>
>>
>>
>>
>>
>>
>> -- System Information:
>> Debian Release: squeeze/sid
>> APT prefers unstable
>> APT policy: (901, 'unstable'), (900, 'testing'), (300, 'experimental')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
>> Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/bash
>>
>> Versions of packages python-matplotlib depends on:
>> ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit
>> ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib
>> ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra
>> ii libfontconfig1 2.8.0-2 generic font configuration library
>> ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib
>> ii libgcc1 1:4.4.2-2 GCC support library
>> ii libglib2.0-0 2.22.4-1 The GLib library of C routines
>> ii libgtk2.0-0 2.18.6-1 The GTK+ graphical user interface
>> ii libpango1.0-0 1.26.0-1 Layout and rendering of internatio
>> ii libpng12-0 1.2.40-1 PNG library - runtime
>> ii libstdc++6 4.4.2-2 The GNU Standard C++ Library v3
>> ii python 2.5.4-9 An interactive high-level object-o
>> ii python-cairo 1.8.6-1 Python bindings for the Cairo vect
>> ii python-dateutil 1.4.1-3 powerful extensions to the standar
>> ii python-gobject 2.16.1-1 Python bindings for the GObject li
>> ii python-matplotlib-data 0.99.1.2-3 Python based plotting system (data
>> ii python-numpy 1:1.3.0-3+b1 Numerical Python adds a fast array
>> ii python-pyparsing 1.5.2-1 Python parsing module
>> ii python-support 1.0.6.1 automated rebuilding support for P
>> ii python-tz 2009l-1 Python version of the Olson timezo
>> ii tcl8.5 8.5.7-1 Tcl (the Tool Command Language) v8
>> ii tk8.5 8.5.7-1 Tk toolkit for Tcl and X11, v8.5 -
>> ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
>>
>> Versions of packages python-matplotlib recommends:
>> ii python-glade2 2.16.0-1 GTK+ bindings: Glade support
>> ii python-tk 2.5.2-1.1 Tkinter - Writing Tk applications
>>
>> Versions of packages python-matplotlib suggests:
>> ii dvipng 1.11-1 convert DVI files to PNG graphics
>> ii ipython 0.10-1 enhanced interactive Python shell
>> ii librsvg2-common 2.26.0-1 SAX-based renderer library for SVG
>> ii python-configobj 4.5.2-2 a simple but powerful config file
>> pn python-excelerator <none> (no description available)
>> ii python-gtk2 2.16.0-1 Python bindings for the GTK+ widge
>> ii python-matplotlib-doc 0.99.0-1 Python based plotting system (docu
>> pn python-qt3 <none> (no description available)
>> ii python-qt4 4.6-1 Python bindings for Qt4
>> ii python-scipy 0.7.0-2+b1 scientific tools for Python
>> ii python-traits 3.2.0-1 Manifest typing and reactive progr
>> ii python-wxgtk2.8 2.8.10.1-3 wxWidgets Cross-platform C++ GUI t
>> ii texlive-extra-utils 2007.dfsg.2-7 TeX Live: TeX auxiliary programs
>> ii texlive-latex-extra 2007.dfsg.17-2 TeX Live: LaTeX supplementary pack
>>
>> -- no debconf information
>>
>>
>>
>> _______________________________________________
>> Python-modules-team mailing list
>> Pyt...@li...
>> http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
>>
> 
> 
> 

forwarded 573179 mat...@li...
thanks
Hello Matplotlib developers,
I'm forwarding this bug a Debian user reported some days ago. It would
be nice it you could give it a look
Thanks in advance,
Sandro
On Tue, Mar 9, 2010 at 17:05, Yaroslav Halchenko <de...@on...> wrote:
> Package: python-matplotlib
> Version: 0.99.1.2-3
> Severity: normal
>
>
> throws an exception while comparing two masked arrays which have no values (all
> masked out)... sure thing it can't determine vmin/vmax to be used (unless clim
> is used explicitely), but the exception which is thrown is non-informative. I
> thought that upstream might want to make it more user-friendly -- please
> forward upstream.
>
> Here is the code to reproduce:
> import pylab as pl
> import numpy as np
>
> size = (5, 5)
> d = np.ones(size)
> mask = d.astype(bool)
>
> md = np.ma.masked_array(d, mask)
> pl.imshow(md)
> # explicit clim would eliminate the problem
> #pl.clim(0, 1)
> pl.colorbar()
>
> and here is the traceback:
>
> Traceback (most recent call last):
> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1417, in __call__
>  return self.func(*args)
> File "/usr/lib/pymodules/python2.5/matplotlib/backends/backend_tkagg.py", line 212, in resize
>  self.show()
> File "/usr/lib/pymodules/python2.5/matplotlib/backends/backend_tkagg.py", line 215, in draw
>  FigureCanvasAgg.draw(self)
> File "/usr/lib/pymodules/python2.5/matplotlib/backends/backend_agg.py", line 314, in draw
>  self.figure.draw(self.renderer)
> File "/usr/lib/pymodules/python2.5/matplotlib/artist.py", line 46, in draw_wrapper
>  draw(artist, renderer, *kl)
> File "/usr/lib/pymodules/python2.5/matplotlib/figure.py", line 773, in draw
>  for a in self.axes: a.draw(renderer)
> File "/usr/lib/pymodules/python2.5/matplotlib/artist.py", line 46, in draw_wrapper
>  draw(artist, renderer, *kl)
> File "/usr/lib/pymodules/python2.5/matplotlib/axes.py", line 1701, in draw
>  im.draw(renderer)
> File "/usr/lib/pymodules/python2.5/matplotlib/artist.py", line 46, in draw_wrapper
>  draw(artist, renderer, *kl)
> File "/usr/lib/pymodules/python2.5/matplotlib/image.py", line 237, in draw
>  im = self.make_image(renderer.get_image_magnification())
> File "/usr/lib/pymodules/python2.5/matplotlib/image.py", line 182, in make_image
>  x = self.to_rgba(self._A, self._alpha)
> File "/usr/lib/pymodules/python2.5/matplotlib/cm.py", line 166, in to_rgba
>  x = self.norm(x)
> File "/usr/lib/pymodules/python2.5/matplotlib/colors.py", line 763, in __call__
>  elif vmin==vmax:
> File "/usr/lib/python2.5/site-packages/numpy/ma/core.py", line 3119, in __eq__
>  check._mask = mask
> AttributeError: 'numpy.bool_' object has no attribute '_mask'
>
>
>
>
>
>
> -- System Information:
> Debian Release: squeeze/sid
> APT prefers unstable
> APT policy: (901, 'unstable'), (900, 'testing'), (300, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages python-matplotlib depends on:
> ii libatk1.0-0       1.28.0-1     The ATK accessibility toolkit
> ii libc6          2.10.2-5     Embedded GNU C Library: Shared lib
> ii libcairo2        1.8.8-2     The Cairo 2D vector graphics libra
> ii libfontconfig1     2.8.0-2     generic font configuration library
> ii libfreetype6      2.3.11-1     FreeType 2 font engine, shared lib
> ii libgcc1         1:4.4.2-2    GCC support library
> ii libglib2.0-0      2.22.4-1     The GLib library of C routines
> ii libgtk2.0-0       2.18.6-1     The GTK+ graphical user interface
> ii libpango1.0-0      1.26.0-1     Layout and rendering of internatio
> ii libpng12-0       1.2.40-1     PNG library - runtime
> ii libstdc++6       4.4.2-2     The GNU Standard C++ Library v3
> ii python         2.5.4-9     An interactive high-level object-o
> ii python-cairo      1.8.6-1     Python bindings for the Cairo vect
> ii python-dateutil     1.4.1-3     powerful extensions to the standar
> ii python-gobject     2.16.1-1     Python bindings for the GObject li
> ii python-matplotlib-data 0.99.1.2-3    Python based plotting system (data
> ii python-numpy      1:1.3.0-3+b1   Numerical Python adds a fast array
> ii python-pyparsing    1.5.2-1     Python parsing module
> ii python-support     1.0.6.1     automated rebuilding support for P
> ii python-tz        2009l-1     Python version of the Olson timezo
> ii tcl8.5         8.5.7-1     Tcl (the Tool Command Language) v8
> ii tk8.5          8.5.7-1     Tk toolkit for Tcl and X11, v8.5 -
> ii zlib1g         1:1.2.3.4.dfsg-3 compression library - runtime
>
> Versions of packages python-matplotlib recommends:
> ii python-glade2         2.16.0-1  GTK+ bindings: Glade support
> ii python-tk           2.5.2-1.1 Tkinter - Writing Tk applications
>
> Versions of packages python-matplotlib suggests:
> ii dvipng          1.11-1     convert DVI files to PNG graphics
> ii ipython          0.10-1     enhanced interactive Python shell
> ii librsvg2-common      2.26.0-1    SAX-based renderer library for SVG
> ii python-configobj     4.5.2-2    a simple but powerful config file
> pn python-excelerator    <none>     (no description available)
> ii python-gtk2        2.16.0-1    Python bindings for the GTK+ widge
> ii python-matplotlib-doc   0.99.0-1    Python based plotting system (docu
> pn python-qt3        <none>     (no description available)
> ii python-qt4        4.6-1     Python bindings for Qt4
> ii python-scipy       0.7.0-2+b1   scientific tools for Python
> ii python-traits       3.2.0-1    Manifest typing and reactive progr
> ii python-wxgtk2.8      2.8.10.1-3   wxWidgets Cross-platform C++ GUI t
> ii texlive-extra-utils    2007.dfsg.2-7 TeX Live: TeX auxiliary programs
> ii texlive-latex-extra    2007.dfsg.17-2 TeX Live: LaTeX supplementary pack
>
> -- no debconf information
>
>
>
> _______________________________________________
> Python-modules-team mailing list
> Pyt...@li...
> http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
>
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

> 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.
I can try to do this. I think I would prefer, however, not to resize
the "self" axes and continue with my current approach of creating two
new axes within the original axes. On the user end, I think it makes
more sense to set the title and ylabel of the main axes, rather than
setting them for the individual upper and lower axes. More on that
below.
>> 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?
>
> klukas, I'm afraid I don't understand your issue... Can you explain using it differently?
In my approach, you end up with a main axes object that is invisible,
and then two visible axes objects (upper and lower) within the main
axes. I would ideally like to have the y label display in the middle
of the main y-axis, independent of where the break lies. If I place a
y label on the main axes (which has ticks or tick labels), though, it
appears right up against the axis line. I'd like it to be placed
further to the left, clear of the tick labels that appear on the upper
and lower axes. So, I'd like to be able to access whatever algorithm
is used to choose the offset of the axis label, and explicitly set the
offset of the ylabel for the main axes so that it clears the tick
labels.
// Jeff

Replying to everyone at the same time: (spot the person in the UK!)
Chris Barker wrote:
> That would be better as (ntri, 3), to be compatible with the usual C
> ordering of numpy arrays.
Of course.
John Hunter wrote:
> 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. <snip>
> 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've taken a look at CXX and it looks like a much more pleasant
solution, so I'm happy to use that instead.
> 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.
Understood. I'm uneasy about making a major commitment at this stage
as I'm new to open source contributions, so how about you ask me again
when I've submitted the code and people have had the chance to
review/correct/admire/destroy it?
> Eric Firing wrote:
> 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 like the idea of putting it in its own directory under lib/matplotlib.
> What sort of timeline do you have in mind?
I am currently "between jobs", which leaves me plenty of spare time
for interesting projects. I reckon I should have something worthy of
consideration in 2 weeks time.
Ian

Hi,
> Date: 2010年3月15日 13:16:59 -0700 (PDT)
> From: klukas <kl...@wi...>
>
> 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've fudged something similar recently, using a more hacky approach. I
wanted to display a time series with potentially large gaps in its
recording, so I figured out a way to remove the gaps from the plot by
"compacting" the x data, but adjusting the x tick labels to reflect
the original values of the data. Here is an example:
Suppose I have two segments in my time series that are far apart in
time. The segments typically have different lengths. Both the x and y
data are stored as a sequence of 2 arrays (1 per segment), e.g.
x = [ [3, 4, 5, 6, 7, 8, 9], [340, 342, 344, 346, 348] ]
y = [ [ ... ], [ ... ] ]
I only focus on the x (time) axis in this case. I compact the x values
so that the minimum value of the first segment is 0, and the minimum
value of each subsequent segment is equal to the maximum value of the
segment to the left of it. This preserves the relative x-spacing
between the points of the same segment, but shifts the segments to sit
right next to each other. For the above example, I subtract an offset
of 3 for the first segment and 334 for the second segment to get:
compacted_x = [ [0, 1, 2, 3, 4, 5, 6], [6, 8, 10, 12, 14] ]
I then plot the (compacted_x, y) segments as usual on a single Axes,
in my case using a LineCollection. Afterwards, I define a new tick
formatter derived from the standard mpl.ticker.ScalarFormatter that
determines which segment contains the x-value it is called with and
then adds back the appropriate offset before creating the tick label.
I also add dashed vertical "break lines" to indicate the breaks
between segments.
This scheme works especially well for monotonically increasing ticks
(such as time series). I can provide code if anyone is interested.
I've extended it to x and y axes, and it will split image segments in
the same way as line segments (for spectrograms, for example). The
only major current downside is that the cursor displays the compacted
x-value when hovering over the plot (maybe this could be fixed too?).
Regards,
Ludwig

John Hunter wrote:
> 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.
>>
>> 
> 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.
>
>
> 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?
> 
John, I'm attaching a helper function I wrote to do just this.
Unfortunately, I don't have time to attempt to merge this into MPL right
now...
On Mon, Mar 15, 2010 at 3:16 PM, klukas <kl...@wi...> wrote:
> 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?
klukas, I'm afraid I don't understand your issue... Can you explain using it differently?
-Andrew

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