matplotlib-devel Mailing List for matplotlib (Page 2)

On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> wrote:

> By the way, given that we now have "suplots" in the pyplot namespace,
>> can we have sca also?
>>
>
> Done in svn 8205.
>


Eric,

A minor question. I wonder whether an explicit for-loop inside pyplot.sca is
necessary?
Here is a slight variation w/o a for-loop (well, the for-loop is implicitly
done with the "in" operator I guess) that seems to work for me, but I may be
missing something.

    managers = _pylab_helpers.Gcf.get_all_fig_managers()
    if ax.figure.canvas.manager in managers and \
           ax in ax.figure.axes:
        _pylab_helpers.Gcf.set_active(ax.figure.canvas.manager)
        ax.figure.sca(ax)
        return
    raise ValueError("Axes instance argument was not found in a figure.")

Regards,

-JJ

On Sun, Mar 21, 2010 at 2:30 PM, Eric Firing <ef...@ha...> wrote:
> Is the added complexity, scrambling pylab into the OO layer, and need for
> explanation, really worth the gain?  As far as I can see, it merely adds
one
> more way to do something--and not a particularly recommended way.  It is
no
> more concise than using sca().  It may be slightly more readable because
of
> the indentation, but that is the only advantage I see.
>

* complexity

   I guess the code below is a "minimal" implementation (it worked okay with
my limited tests).

   # context manager

   def __enter__(self):

       import matplotlib.pyplot as plt

       plt.sca(self)

       return self

   def __exit__(self, type, value, tb):

       pass


* readability

1) with "with" statement

fig, axarr = subplots(2,2)


> for ax1, ax2 in axarr:

    with ax1:

        plot([1,2,3])


>     with ax2:

       plot([2,3,4])


2) with "sca"


> fig, axarr = subplots(2,2)


> for ax1, ax2 in axarr:

   sca(ax1)

   plot([1,2,3])


>    sca(ax2)

   plot([2,3,4])



While I certainly prefer 1) over 2) as far as the readability is concerned,
I currently don't have a strong opinion whether the readability beats the
complexity in this case.

So, unless there are more of positive feedbacks from others, I'll consider
it dropped.

Regards,

-JJ

Ryan May wrote:
> On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
>>>> Or, how about we make axes an context manager.
>>> This would require dropping support for Python 2.4.
>> I don't think making the Axes a context manager means dropping python
>> 2.4 support
>> (note that I'm not saying we use "with" statement in the mpl source).
>> Everything should work fine in python 2.4 (please correct me if I'm wrong).
>> It just gives a user a choice. If a user runs his/her script with
>> python 2.5 and higher, he/she has an option to use an axes as an
>> context manager. Of course, if he/she want his/her own code supported
>> in python 2.4, he/she should not use "with" statement.
> 
> I see what you're saying.  While the use of the language syntax is
> restricted to 2.5 and above, we could add the needed methods to the
> Axes object, which would just be ignored by python <2.5.  That's not a
> bad idea.
> 
> I'm +1 on the idea.


Is the added complexity, scrambling pylab into the OO layer, and need 
for explanation, really worth the gain?  As far as I can see, it merely 
adds one more way to do something--and not a particularly recommended 
way.  It is no more concise than using sca().  It may be slightly more 
readable because of the indentation, but that is the only advantage I see.

Eric

> 
> Ryan
> 

On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
>>> Or, how about we make axes an context manager.
>>
>> This would require dropping support for Python 2.4.
>
> I don't think making the Axes a context manager means dropping python
> 2.4 support
> (note that I'm not saying we use "with" statement in the mpl source).
> Everything should work fine in python 2.4 (please correct me if I'm wrong).
> It just gives a user a choice. If a user runs his/her script with
> python 2.5 and higher, he/she has an option to use an axes as an
> context manager. Of course, if he/she want his/her own code supported
> in python 2.4, he/she should not use "with" statement.

I see what you're saying.  While the use of the language syntax is
restricted to 2.5 and above, we could add the needed methods to the
Axes object, which would just be ignored by python <2.5.  That's not a
bad idea.

I'm +1 on the idea.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
>
> Done in svn 8205.
>

Thanks!

>>
>> Or, how about we make axes an context manager.
>
> This would require dropping support for Python 2.4.

I don't think making the Axes a context manager means dropping python
2.4 support
(note that I'm not saying we use "with" statement in the mpl source).
Everything should work fine in python 2.4 (please correct me if I'm wrong).
It just gives a user a choice. If a user runs his/her script with
python 2.5 and higher, he/she has an option to use an axes as an
context manager. Of course, if he/she want his/her own code supported
in python 2.4, he/she should not use "with" statement.

Regards,

-JJ

Ryan May wrote:
> On Sat, Mar 20, 2010 at 5:53 PM, Eric Firing <ef...@ha...> wrote:
>> Ryan May wrote:
>>> Hi,
>>>
>>> I just started running PyGTK 2.16 and noticed the following everytime
>>> I run a matplotlib script:
>>>
>>>
>>> /home/rmay/.local/lib/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621:
>>> DeprecationWarning: Use the new widget gtk.Tooltip
>>>  self.tooltips = gtk.Tooltips()
>>>
>>> Right now, we support >= PyGTK 2.2.  The new, non-deperecated API
>> pygtk_version_required = (2,4,0)
> 
> Ok. I got my number from our install docs:
> http://matplotlib.sourceforge.net/users/installing.html#build-requirements
> There it says PyGTK 2.2 as a (optional) build dependency.

Fixed in svn, thanks.

Eric

On Sat, Mar 20, 2010 at 5:53 PM, Eric Firing <ef...@ha...> wrote:
> Ryan May wrote:
>>
>> Hi,
>>
>> I just started running PyGTK 2.16 and noticed the following everytime
>> I run a matplotlib script:
>>
>>
>> /home/rmay/.local/lib/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621:
>> DeprecationWarning: Use the new widget gtk.Tooltip
>>  self.tooltips = gtk.Tooltips()
>>
>> Right now, we support >= PyGTK 2.2.  The new, non-deperecated API
>
> pygtk_version_required = (2,4,0)

Ok. I got my number from our install docs:
http://matplotlib.sourceforge.net/users/installing.html#build-requirements
There it says PyGTK 2.2 as a (optional) build dependency.

>> (gtk.Tooltip) was added in 2.12 (and the gtk.Tooltips API was
>> deprecated at this time).  So, my question is how do we want to handle
>> this?  Do we want to create a helper method that hides the logic to
>> determine what method to use (there doesn't look to be an easy way to
>> support both)? Or do we just bump our required version? 2.12.0 was
>> released in fall 2007. I'm not sure what versions are supplied with
>> the various distros.
>>
>
> My sense is that RHEL4 is still common, and will be supported by RH through
> early 2012 (http://www.redhat.com/security/updates/errata/).  It is way back
> at pygtk 2.4.
>
> I just now committed to svn a little bit of conditional code to support the
> new api along with the old one.  Minimal testing on my system (new api)
> looks OK; more testing with new API, and testing with pygtk < 2.12, are
> needed.  The changes are extremely simple, but I might have overlooked
> something.

Awesome, works great here, thanks.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Jae-Joon Lee wrote:

> 
> By the way, given that we now have "suplots" in the pyplot namespace,
> can we have sca also?

Done in svn 8205.

> For example,
> 
>  # Two subplots, the axes array is 1-d
>  f, axarr = subplots(2, sharex=True)
> 
>  sca(axarr[0])
>  plot(x, y)
>  title('Sharing X axis')
> 
>  sca(axarr[1])
>  scatter(x, y)
> 
> Or, how about we make axes an context manager.

This would require dropping support for Python 2.4.

Eric

> 
>  # Two subplots, the axes array is 1-d
>  f, axarr = subplots(2, sharex=True)
> 
>  with axarr[0]:
>    plot(x, y)
>    title('Sharing X axis')
> 
>  with axarr[1]:
>    scatter(x, y)
> 
> This may not very useful in the interactive mode, but may make a
> script (written in pylab mode) more readable.
> 
> Regards,
> 
> -JJ

On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez <fpe...@gm...> wrote:
> I wonder if it's possible to put things like a draw_if_interactive()
> call at the end of the OO methods... I realize that pyplot was the
> only one meant to do that, but if we are to encourage using the OO api
> more, then it's going to have to be as pleasant to use as pyplot...  I
> don't know the codebase well enough to mess with this right now, so I
> hope someone who's more versed in that part of the code can make a fix
> for this whose  impact isn't too severe on the runtime of OO code.

I'm not very inclined to this but I'll wait to hear what others think.
I use oo api in the interactive mode but I still prefer to call draw()
explicitly.
Of course, we can make it optional.

By the way, given that we now have "suplots" in the pyplot namespace,
can we have sca also?
For example,

 # Two subplots, the axes array is 1-d
 f, axarr = subplots(2, sharex=True)

 sca(axarr[0])
 plot(x, y)
 title('Sharing X axis')

 sca(axarr[1])
 scatter(x, y)

Or, how about we make axes an context manager.

 # Two subplots, the axes array is 1-d
 f, axarr = subplots(2, sharex=True)

 with axarr[0]:
   plot(x, y)
   title('Sharing X axis')

 with axarr[1]:
   scatter(x, y)

This may not very useful in the interactive mode, but may make a
script (written in pylab mode) more readable.

Regards,

-JJ

Ryan May wrote:
> Hi,
> 
> I just started running PyGTK 2.16 and noticed the following everytime
> I run a matplotlib script:
> 
> /home/rmay/.local/lib/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621:
> DeprecationWarning: Use the new widget gtk.Tooltip
>   self.tooltips = gtk.Tooltips()
> 
> Right now, we support >= PyGTK 2.2.  The new, non-deperecated API

pygtk_version_required = (2,4,0)

> (gtk.Tooltip) was added in 2.12 (and the gtk.Tooltips API was
> deprecated at this time).  So, my question is how do we want to handle
> this?  Do we want to create a helper method that hides the logic to
> determine what method to use (there doesn't look to be an easy way to
> support both)? Or do we just bump our required version? 2.12.0 was
> released in fall 2007. I'm not sure what versions are supplied with
> the various distros.
> 

My sense is that RHEL4 is still common, and will be supported by RH 
through early 2012 (http://www.redhat.com/security/updates/errata/).  It 
is way back at pygtk 2.4.

I just now committed to svn a little bit of conditional code to support 
the new api along with the old one.  Minimal testing on my system (new 
api) looks OK; more testing with new API, and testing with pygtk < 2.12, 
are needed.  The changes are extremely simple, but I might have 
overlooked something.

Eric

> Thoughts?
> 
> Ryan
> 

Hi,

I just started running PyGTK 2.16 and noticed the following everytime
I run a matplotlib script:

/home/rmay/.local/lib/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621:
DeprecationWarning: Use the new widget gtk.Tooltip
  self.tooltips = gtk.Tooltips()

Right now, we support >= PyGTK 2.2.  The new, non-deperecated API
(gtk.Tooltip) was added in 2.12 (and the gtk.Tooltips API was
deprecated at this time).  So, my question is how do we want to handle
this?  Do we want to create a helper method that hides the logic to
determine what method to use (there doesn't look to be an easy way to
support both)? Or do we just bump our required version? 2.12.0 was
released in fall 2007. I'm not sure what versions are supplied with
the various distros.

Thoughts?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

David J. Raymond wrote:
> On Fri, Mar 19, 2010 at 05:47:05PM -1000, Eric Firing wrote:
>> David J. Raymond wrote:
>>> I am using python 2.5.5 and the gtk background (as far as I can tell).
>>> Turning off path.simplify gets rid of the extraneous line.  I am
>>> attaching pngs with path.simplify both on and off.  I am also
>>> attaching the full coastline file that produced the original problem.
>>> I noticed that the behavior was a bit weird, with the bad line
>>> appearing or disappearing in apparently random ways depending on what
>>> was edited out of the input file.
>> This looks to me like a bug that Mike fixed, maybe the one where a
>> path was not always starting with a move_to.  That was fixed on
>> October 22.
> 
> Would this fix have made it into version 0.99.1.2 which I am currently
> using?
> 
> Dave

No, it is not there.  Can you build from svn?

Eric

On Fri, Mar 19, 2010 at 05:47:05PM -1000, Eric Firing wrote:
> David J. Raymond wrote:
> >I am using python 2.5.5 and the gtk background (as far as I can tell).
> >Turning off path.simplify gets rid of the extraneous line.  I am
> >attaching pngs with path.simplify both on and off.  I am also
> >attaching the full coastline file that produced the original problem.
> >I noticed that the behavior was a bit weird, with the bad line
> >appearing or disappearing in apparently random ways depending on what
> >was edited out of the input file.
> 
> This looks to me like a bug that Mike fixed, maybe the one where a
> path was not always starting with a move_to.  That was fixed on
> October 22.

Would this fix have made it into version 0.99.1.2 which I am currently
using?

Dave

http://mobile-it.com.ar/Ben.html


      

On Thu, Mar 18, 2010 at 6:39 PM, John Hunter <jd...@gm...> wrote:

> 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".

Without further feedback, I went with John's vote on 'subplots' and
have committed the changes to the API as agreed, now naming it
plt.subplots().  I'm sorry but I didn't implement the full
Figure.add_subarray() changes you suggested, ran out of time...

There is, however, a fly in the ointment: while this new code feels
very nice from playing wtih it in scripts like the  example just
committed:

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/examples/pylab_examples/subplots_demo.py?revision=8202&view=markup

it is NOT pleasant to use interactively, because the OO api requires
explicit draw() calls all the time.

I just realized  this now using it more, and  it's a  bummer, because
it makes it less likely that one will use this type of code in
everyday interactive exploration.

I wonder if it's possible to put things like a draw_if_interactive()
call at the end of the OO methods... I realize that pyplot was the
only one meant to do that, but if we are to encourage using the OO api
more, then it's going to have to be as pleasant to use as pyplot...  I
don't know the codebase well enough to mess with this right now, so I
hope someone who's more versed in that part of the code can make a fix
for this whose  impact isn't too severe on the runtime of OO code.

Cheers,

f

ps  - Chris, thanks for the encouragement :)

David J. Raymond wrote:
> I am using python 2.5.5 and the gtk background (as far as I can tell).
> Turning off path.simplify gets rid of the extraneous line.  I am
> attaching pngs with path.simplify both on and off.  I am also
> attaching the full coastline file that produced the original problem.
> I noticed that the behavior was a bit weird, with the bad line
> appearing or disappearing in apparently random ways depending on what
> was edited out of the input file.

This looks to me like a bug that Mike fixed, maybe the one where a path 
was not always starting with a move_to.  That was fixed on October 22.

> 
> By the way, I notice that the default value of
> 'path.simplify_threshold' is 0.1111...  I don't quite know what this
> means, but it sounds pertinent.
> 
> I assume path.simplify is some kind of optimization scheme?

Yes, it is a very fancy and nice set of algorithms for eliminating path 
elements that would not make any visible difference to the output.  It 
makes it possible to plot very large datasets.

Eric

> 
> Dave
> 
> On Fri, Mar 19, 2010 at 03:13:04PM -0400, Michael Droettboom wrote:
>> I can't reproduce anything like a bug, either.  What backend are you
>> using?  Have you tried turning path.simplify on or off?  (Makes no
>> difference here, just seems a likely candidate).
>>
>> Mike
>>
>> Jeff Whitaker wrote:
>>> On 3/19/10 11:10 AM, David J. Raymond wrote:
>>>> I am trying to plot two 1-D masked arrays against each other
>>>> in a line plot and an extraneous straight line appears on
>>>> the plot.  This phenomenon only occurs sporadically and with
>>>> certain data sets.  I have noticed a similar phenomenon with
>>>> masked arrow arrays, but that is much harder to track down.
>>>> The masked elements are intended to break the plot line so
>>>> that several independent polylines are plotted.  (The purpose
>>>> is to plot a map of coastal outlines.)
>>>>
>>>> I am attaching a python script which reproduces the problem,
>>>> but only with a particular data set, which is also attached.
>>>> Sorry, if I try to shorten the data set more than I have
>>>> already, the problem goes away, even if I split the file
>>>> in half an plot each half separately!
>>>>
>>>> I am running on a 32 bit intel processor using debian testing
>>>> and the numpy and matplotlib versions are 1.3 and 0.99.1.2.
>>>> However, the problem also appears on a 64 bit amd processor
>>>> running debian stable with numpy and matplotlib versions
>>>> 1.3 and 0.99.1.1.
>>>>
>>>> The python script is named maskbug.py and the data set is
>>>> trunc1.dat, which is an ascii file.  The data set should be
>>>> read on the standard input, i. e.,
>>>>
>>>>     maskbug.py < trunc1.dat
>>>>
>>>> I have verified by printing the masked arrays that nothing
>>>> appears to go wrong in the conversion from ascii to numpy
>>>> masked array.
>>>>
>>>> Dave Raymond
>>>> Physics Dept.
>>>> New Mexico Tech
>>>> Socorro, NM 87801
>>> Dave:  Can you attach a png image showing what you get?  When I
>>> run your script, I get a plot that reasonable (no obviously crazy
>>> lines running across the plot).
>>>
>>> -Jeff
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>
>>> -- 
>>> Jeffrey S. Whitaker         Phone  : (303)497-6313
>>> Meteorologist               FAX    : (303)497-6449
>>> NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
>>> 325 Broadway                Office : Skaggs Research Cntr 1D-113
>>> Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>> -- 
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> 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 using python 2.5.5 and the gtk background (as far as I can tell).
Turning off path.simplify gets rid of the extraneous line.  I am
attaching pngs with path.simplify both on and off.  I am also
attaching the full coastline file that produced the original problem.
I noticed that the behavior was a bit weird, with the bad line
appearing or disappearing in apparently random ways depending on what
was edited out of the input file.

By the way, I notice that the default value of
'path.simplify_threshold' is 0.1111...  I don't quite know what this
means, but it sounds pertinent.

I assume path.simplify is some kind of optimization scheme?

Dave

On Fri, Mar 19, 2010 at 03:13:04PM -0400, Michael Droettboom wrote:
> I can't reproduce anything like a bug, either.  What backend are you
> using?  Have you tried turning path.simplify on or off?  (Makes no
> difference here, just seems a likely candidate).
> 
> Mike
> 
> Jeff Whitaker wrote:
> >On 3/19/10 11:10 AM, David J. Raymond wrote:
> >>I am trying to plot two 1-D masked arrays against each other
> >>in a line plot and an extraneous straight line appears on
> >>the plot.  This phenomenon only occurs sporadically and with
> >>certain data sets.  I have noticed a similar phenomenon with
> >>masked arrow arrays, but that is much harder to track down.
> >>The masked elements are intended to break the plot line so
> >>that several independent polylines are plotted.  (The purpose
> >>is to plot a map of coastal outlines.)
> >>
> >>I am attaching a python script which reproduces the problem,
> >>but only with a particular data set, which is also attached.
> >>Sorry, if I try to shorten the data set more than I have
> >>already, the problem goes away, even if I split the file
> >>in half an plot each half separately!
> >>
> >>I am running on a 32 bit intel processor using debian testing
> >>and the numpy and matplotlib versions are 1.3 and 0.99.1.2.
> >>However, the problem also appears on a 64 bit amd processor
> >>running debian stable with numpy and matplotlib versions
> >>1.3 and 0.99.1.1.
> >>
> >>The python script is named maskbug.py and the data set is
> >>trunc1.dat, which is an ascii file.  The data set should be
> >>read on the standard input, i. e.,
> >>
> >>     maskbug.py < trunc1.dat
> >>
> >>I have verified by printing the masked arrays that nothing
> >>appears to go wrong in the conversion from ascii to numpy
> >>masked array.
> >>
> >>Dave Raymond
> >>Physics Dept.
> >>New Mexico Tech
> >>Socorro, NM 87801
> >
> >Dave:  Can you attach a png image showing what you get?  When I
> >run your script, I get a plot that reasonable (no obviously crazy
> >lines running across the plot).
> >
> >-Jeff
> >>
> >>
> >>------------------------------------------------------------------------------
> >>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
> >
> >
> >-- 
> >Jeffrey S. Whitaker         Phone  : (303)497-6313
> >Meteorologist               FAX    : (303)497-6449
> >NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
> >325 Broadway                Office : Skaggs Research Cntr 1D-113
> >Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg
> >------------------------------------------------------------------------
> >
> >------------------------------------------------------------------------------
> >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
> 
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
> 

Here is a minor patch for the mplot3d.view_init() function.  It:

 1. comments this method so that users know that they can use it to programatically rotate or re-set the axes. 
 2. adds some new functionality so that if no parameters are passed in, the default values (what was specified in the Axes3D constructor) are used instead.

This diff was created with SVN head revision 8199.

I tested the new feature with my own code to verify it works, but don't have any example code or test scripts to submit. 

Thanks,
-Ben

I can't reproduce anything like a bug, either.  What backend are you 
using?  Have you tried turning path.simplify on or off?  (Makes no 
difference here, just seems a likely candidate).

Mike

Jeff Whitaker wrote:
> On 3/19/10 11:10 AM, David J. Raymond wrote:
>> I am trying to plot two 1-D masked arrays against each other
>> in a line plot and an extraneous straight line appears on
>> the plot.  This phenomenon only occurs sporadically and with
>> certain data sets.  I have noticed a similar phenomenon with
>> masked arrow arrays, but that is much harder to track down.
>> The masked elements are intended to break the plot line so
>> that several independent polylines are plotted.  (The purpose
>> is to plot a map of coastal outlines.)
>>
>> I am attaching a python script which reproduces the problem,
>> but only with a particular data set, which is also attached.
>> Sorry, if I try to shorten the data set more than I have
>> already, the problem goes away, even if I split the file
>> in half an plot each half separately!
>>
>> I am running on a 32 bit intel processor using debian testing
>> and the numpy and matplotlib versions are 1.3 and 0.99.1.2.
>> However, the problem also appears on a 64 bit amd processor
>> running debian stable with numpy and matplotlib versions
>> 1.3 and 0.99.1.1.
>>
>> The python script is named maskbug.py and the data set is
>> trunc1.dat, which is an ascii file.  The data set should be
>> read on the standard input, i. e.,
>>
>>      maskbug.py < trunc1.dat
>>
>> I have verified by printing the masked arrays that nothing
>> appears to go wrong in the conversion from ascii to numpy
>> masked array.
>>
>> Dave Raymond
>> Physics Dept.
>> New Mexico Tech
>> Socorro, NM 87801
>>   
>
> Dave:  Can you attach a png image showing what you get?  When I run 
> your script, I get a plot that reasonable (no obviously crazy lines 
> running across the plot).
>
> -Jeff
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>   
>
>
> -- 
> Jeffrey S. Whitaker         Phone  : (303)497-6313
> Meteorologist               FAX    : (303)497-6449
> NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
> 325 Broadway                Office : Skaggs Research Cntr 1D-113
> Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Fernando Perez wrote:
> I personally think that
> this should be the way to use mpl in general when scripting, and the
> way I want to teach,

+ Inf !

I've wanted to do this for years (make a easier way to do scripting the 
OO way), but I only get around to a tiny fraction of the things I want 
to do.

> 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'll leave the name decisions to you folks, I just wanted to be encouraging!

-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 3/19/10 11:10 AM, David J. Raymond wrote:
> I am trying to plot two 1-D masked arrays against each other
> in a line plot and an extraneous straight line appears on
> the plot.  This phenomenon only occurs sporadically and with
> certain data sets.  I have noticed a similar phenomenon with
> masked arrow arrays, but that is much harder to track down.
> The masked elements are intended to break the plot line so
> that several independent polylines are plotted.  (The purpose
> is to plot a map of coastal outlines.)
>
> I am attaching a python script which reproduces the problem,
> but only with a particular data set, which is also attached.
> Sorry, if I try to shorten the data set more than I have
> already, the problem goes away, even if I split the file
> in half an plot each half separately!
>
> I am running on a 32 bit intel processor using debian testing
> and the numpy and matplotlib versions are 1.3 and 0.99.1.2.
> However, the problem also appears on a 64 bit amd processor
> running debian stable with numpy and matplotlib versions
> 1.3 and 0.99.1.1.
>
> The python script is named maskbug.py and the data set is
> trunc1.dat, which is an ascii file.  The data set should be
> read on the standard input, i. e.,
>
>       maskbug.py<  trunc1.dat
>
> I have verified by printing the masked arrays that nothing
> appears to go wrong in the conversion from ascii to numpy
> masked array.
>
> Dave Raymond
> Physics Dept.
> New Mexico Tech
> Socorro, NM 87801
>    

Dave:  Can you attach a png image showing what you get?  When I run your 
script, I get a plot that reasonable (no obviously crazy lines running 
across the plot).

-Jeff
>
>
> ------------------------------------------------------------------------------
> 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
>    


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

I am trying to plot two 1-D masked arrays against each other
in a line plot and an extraneous straight line appears on
the plot.  This phenomenon only occurs sporadically and with
certain data sets.  I have noticed a similar phenomenon with
masked arrow arrays, but that is much harder to track down.
The masked elements are intended to break the plot line so
that several independent polylines are plotted.  (The purpose
is to plot a map of coastal outlines.)

I am attaching a python script which reproduces the problem,
but only with a particular data set, which is also attached.
Sorry, if I try to shorten the data set more than I have
already, the problem goes away, even if I split the file
in half an plot each half separately!

I am running on a 32 bit intel processor using debian testing
and the numpy and matplotlib versions are 1.3 and 0.99.1.2.
However, the problem also appears on a 64 bit amd processor
running debian stable with numpy and matplotlib versions
1.3 and 0.99.1.1.

The python script is named maskbug.py and the data set is
trunc1.dat, which is an ascii file.  The data set should be
read on the standard input, i. e.,

     maskbug.py < trunc1.dat

I have verified by printing the masked arrays that nothing
appears to go wrong in the conversion from ascii to numpy
masked array.

Dave Raymond
Physics Dept.
New Mexico Tech
Socorro, NM 87801

This is indeed a very interesting result and I am able to reproduce 
similar ratios for total running time.

However, I think the semilogx result is somewhat of a red herring.  If 
you change the order of the tests in your script, you'll notice that the 
first "*log*" plot always takes the longest run time.  If you run each 
test in a separate process, all of the "*log*" run times are 
approximately equal (with loglog being slightly slower).  The reason for 
this is the caching of mathtext expressions.  I agree that mathtext is 
the bottleneck -- but mathtext expressions are only parsed and rendered 
the first time they are encountered, and simply pulled from a cache 
after that.

It's sort of a "known issue" that mathtext is slow-ish.  It's a very 
function-call heavy and object-oriented bit of code and most attempts at 
optimization seem to lead to too much uglification.  The algorithms 
themselves are from TeX, so I don't know if there's much room for 
improvement, but there is something about the translation from Pascal/C 
to Python that creates a very different performance profile.

An interesting result may be to disable the mathtext rendering for log 
plots (by setting the axis formatters to something static) and comparing 
those numbers.  That would give a better sense of the overhead of merely 
log-transforming the points and the transformation system itself.  I 
don't think a factor of 2 is too problematic, given all of the extra 
work that has to be done to maintain two copies of the data, extra care 
to calculate xlim and ylim etc.

Mike

Andrew Hawryluk wrote:
> 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
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

> Hello,

> How did you get the cumtime listing? The output of the run doesn't produce a
> cumulative sum table as you showed here.

> Gökhan


No, it doesn't. The output of the run is four huge cProfile listings,
one for each plotting command tested. I manually searched the data for
long cumtime's that differed between the plots and typed the table myself.

I have also confirmed the speed differences on matplotlib 0.99.0 under
Ubuntu 9.10:

plot      0.629 CPU seconds
semilogx  3.430 CPU seconds
semilogy  1.044 CPU seconds
loglog    1.479 CPU seconds

I'll try to figure out why semilogx uses so much more mathtext than
semilogy, but if anyone familiar with the code is curious enough to
look into it they will probably beat me to the answer.

Andrew

On Thu, Mar 18, 2010 at 6:21 PM, Andrew Hawryluk <HA...@no...>wrote:

> 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
>
>
>
Hello,

How did you get the cumtime listing? The output of the run doesn't produce a
cumulative sum table as you showed here.

================================================================================
Platform     :
Linux-2.6.31.9-174.fc12.i686.PAE-i686-with-fedora-12-Constantine
Python       : ('CPython', 'tags/r262', '71600')
NumPy        : 1.5.0.dev8038
Matplotlib   : 1.0.svn
================================================================================



-- 
Gökhan