matplotlib-devel Mailing List for matplotlib

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

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