matplotlib-devel Mailing List for matplotlib

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