Re: [matplotlib-devel] custom window titles
On Thursday 15 November 2007 03:27:28 pm Darren Dale wrote:
> I have a script that is generating many plots, and would like to create
> some more informative window titles than "Figure 1" through "Figure 50". Is
> there an easier way to do it than this, which is specific to backend_qt4?
>
> fig = figure()
> fig.canvas.window().setWindowTitle('Hi')
Please disregard. I hit the send button too quickly:
fig.canvas.set_window_title("D'oh!")
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] custom window titles
I have a script that is generating many plots, and would like to create some
more informative window titles than "Figure 1" through "Figure 50". Is there
an easier way to do it than this, which is specific to backend_qt4?
fig = figure()
fig.canvas.window().setWindowTitle('Hi')
Thanks,
Darren
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Speed improvements on the branch
John Hunter wrote:
> On Nov 15, 2007 12:53 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> Thought some of you may be interested to know that the speed on the
>> branch is getting much better. Whereas earlier the branch was about 2x
>> slower than the trunk, now most things are close to equal with the trunk
>> speed-wise (with a few outliers for some things such as auto legends,
>> quivers and the pcolor stuff that Eric and I have been working on).
>
> Hey Michael, this is very encouraging I just wanted to let know about
> another important use case which I think you are aware of because
> you've referred to optimized marker drawing in the past, but this is
> something I put a lot of effort into (the agg cached marker rasters in
> extension code) because it is an important use case. The script below
> is a useful test, with performance numbers below
>
>
> import time
> import numpy as n
> import matplotlib
> matplotlib.use('Agg')
> from pylab import figure
>
> fig = figure()
> ax = fig.add_subplot(111)
> for i in range(1,7):
> N = 10**i
> x, y = n.random.rand(2,N)
> ax.cla()
> tstart = time.time()
> ax.plot(x, y, 'o')
> fig.canvas.draw()
> print 'N=%d; elapsed=%1.3f'%(N, time.time()-tstart)
>
>
> Trunk:
> N=10; elapsed=0.139
> N=100; elapsed=0.092
> N=1000; elapsed=0.082
> N=1; elapsed=0.133
> N=10; elapsed=0.594
> N=100; elapsed=5.193
>
>
> Branch:
> N=10; elapsed=0.207
> N=100; elapsed=0.118
> N=1000; elapsed=0.138
> N=1; elapsed=0.280
> N=10; elapsed=1.671
> N=100; elapsed=15.877
Very odd. I've been running my own very similar benchmark as I've been
going, and the two code bases perform quite similarly. The branch
continues to cache the markers in more or less the same way as on the
trunk. Here are my results with your benchmark:
Trunk:
N=10; elapsed=0.056
N=100; elapsed=0.039
N=1000; elapsed=0.042
N=1; elapsed=0.067
N=10; elapsed=0.326
N=100; elapsed=2.913
Branch:
N=10; elapsed=0.033
N=100; elapsed=0.028
N=1000; elapsed=0.030
N=1; elapsed=0.055
N=10; elapsed=0.310
N=100; elapsed=2.858
I wonder what environmental and/or hardware difference could cause this?
Perhaps a fresh rebuild would make a difference? (Due to distutils'
lack of dependency tracking...?)
>> log_demo.py 1.769 2.011 0.242113%
>
>
> Here is another area where there is an important difference. Panning
> and zooming interactively with log scaling is much slower on the
> branch, presumably because you have to redo the non-affine part every
> time.
The non-affine part is not computed on every pan and zoom -- that was
one of the main design goals of the branch. (You can put a print
statement in Log10Transform.transform to see when it gets called.) I
can't feel a speed difference between the two, but...
> Also, the old grid line bug on log plots seems to be back, as
> evinced when you zoom from the "home" view.
...I should fix this bug first to have a fair comparison.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Speed improvements on the branch
John Hunter wrote: > On Nov 15, 2007 1:51 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > >> Very odd. I've been running my own very similar benchmark as I've been >> going, and the two code bases perform quite similarly. The branch >> continues to cache the markers in more or less the same way as on the >> trunk. Here are my results with your benchmark: > > Hmm, good guess. I did a clean reinstall of both and the timing > numbers are very close. Thanks for catching this. Phew! I was worried we'd have a real mystery on our hands... ;) -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Speed improvements on the branch
On Nov 15, 2007 1:51 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > Very odd. I've been running my own very similar benchmark as I've been > going, and the two code bases perform quite similarly. The branch > continues to cache the markers in more or less the same way as on the > trunk. Here are my results with your benchmark: Hmm, good guess. I did a clean reinstall of both and the timing numbers are very close. Thanks for catching this. JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Speed improvements on the branch
On Nov 15, 2007 12:53 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Thought some of you may be interested to know that the speed on the
> branch is getting much better. Whereas earlier the branch was about 2x
> slower than the trunk, now most things are close to equal with the trunk
> speed-wise (with a few outliers for some things such as auto legends,
> quivers and the pcolor stuff that Eric and I have been working on).
Hey Michael, this is very encouraging I just wanted to let know about
another important use case which I think you are aware of because
you've referred to optimized marker drawing in the past, but this is
something I put a lot of effort into (the agg cached marker rasters in
extension code) because it is an important use case. The script below
is a useful test, with performance numbers below
import time
import numpy as n
import matplotlib
matplotlib.use('Agg')
from pylab import figure
fig = figure()
ax = fig.add_subplot(111)
for i in range(1,7):
N = 10**i
x, y = n.random.rand(2,N)
ax.cla()
tstart = time.time()
ax.plot(x, y, 'o')
fig.canvas.draw()
print 'N=%d; elapsed=%1.3f'%(N, time.time()-tstart)
Trunk:
N=10; elapsed=0.139
N=100; elapsed=0.092
N=1000; elapsed=0.082
N=1; elapsed=0.133
N=10; elapsed=0.594
N=100; elapsed=5.193
Branch:
N=10; elapsed=0.207
N=100; elapsed=0.118
N=1000; elapsed=0.138
N=1; elapsed=0.280
N=10; elapsed=1.671
N=100; elapsed=15.877
> log_demo.py 1.769 2.011 0.242113%
Here is another area where there is an important difference. Panning
and zooming interactively with log scaling is much slower on the
branch, presumably because you have to redo the non-affine part every
time. Also, the old grid line bug on log plots seems to be back, as
evinced when you zoom from the "home" view.
Anyway, with a few exceptional cases, your new timing results are
starting to look very promising.
Thanks,
JDH
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Speed improvements on the branch
Thought some of you may be interested to know that the speed on the branch is getting much better. Whereas earlier the branch was about 2x slower than the trunk, now most things are close to equal with the trunk speed-wise (with a few outliers for some things such as auto legends, quivers and the pcolor stuff that Eric and I have been working on). Here are the results for the "simple_plot_fps.py" benchmark, which is meant to measure the interactive performance of panning and zooming: trunk: 21.63 fps branch: 23.25 fps Attached are the time differences for everything in backend_driver.py. (Sorted by the percentage difference in speed.) Note that, unlike the above, this measures only one drawing of the plot. It would be interesting to measure the difference in interactive performance for some of these -- I suspect the branch may do better. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA backend agg test a b delta % diff - line_collection.py1.148 0.904 -0.245 78% cohere_demo.py0.958 0.777 -0.182 81% spy_demos.py 0.884 0.807 -0.077 91% pcolor_demo.py1.051 0.984 -0.068 93% scatter_star_poly.py 1.129 1.086 -0.043 96% subplot_demo.py 0.731 0.712 -0.019 97% legend_demo2.py 0.640 0.625 -0.015 97% arctest.py0.596 0.589 -0.007 98% figimage_demo.py 0.537 0.532 -0.005 99% mathtext_demo.py 1.087 1.078 -0.009 99% legend_demo.py0.628 0.623 -0.005 99% text_themes.py0.640 0.636 -0.005 99% two_scales.py 0.684 0.682 -0.002 99% image_demo2.py0.914 0.914 0.000100% masked_demo.py0.668 0.668 0.000100% arrow_demo.py 1.620 1.622 0.002100% simple_plot.py0.610 0.616 0.006100% alignment_test.py 0.576 0.582 0.006101% pcolor_demo2.py 0.745 0.754 0.009101% fonts_demo_kw.py 0.687 0.695 0.008101% image_demo.py 0.732 0.741 0.009101% barh_demo.py 0.645 0.654 0.009101% major_minor_demo1.py 0.658 0.667 0.009101% date_demo2.py 1.185 1.202 0.017101% xcorr_demo.py 0.723 0.734 0.011101% histogram_demo.py 0.961 0.976 0.015101% step_demo.py 0.654 0.665 0.011101% psd_demo.py 0.718 0.730 0.012101% vline_demo.py 0.618 0.630 0.011101% color_demo.py 0.610 0.621 0.012101% scatter_demo2.py 0.944 0.962 0.018101% image_masked.py 0.829 0.845 0.017101% colorbar_only.py 0.494 0.503 0.010102% pcolor_small.py 0.690 0.705 0.015102% invert_axes.py0.611 0.625 0.013102% image_origin.py 0.718 0.736 0.017102% equal_aspect_ratio.py 0.602 0.617 0.015102% unicode_demo.py 0.635 0.653 0.018102% barchart_demo.py 0.641 0.659 0.018102% quadmesh_demo.py 0.765 0.787 0.022102% layer_images.py 0.800 0.823 0.024102% hline_demo.py 0.621 0.641 0.020103% line_collection2.py 0.796 0.822 0.026103% fill_demo.py 0.601 0.624 0.022103% text_handles.py 0.608 0.631 0.023103% stem_plot.py 0.604 0.626 0.023103% figtext.py0.717 0.745 0.028103% broken_barh.py0.678 0.707 0.029104% bar_stacked.py0.626 0.653 0.027104% major_minor_demo2.py 0.779 0.816 0.037104% scatter_demo.py 0.587 0.619 0.032105% axhspan_demo.py
[matplotlib-devel] RFC on basemap changes
I've created a new basemap branch https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits/basemap-testing with lots of under-the-hood optimizations and code refactoring. The most significant change is that I now use the GEOS library (http://geos.refractions.net) to determine whether a given coastline or political boundary feature is within the map projection region or not. If it is, the library clips it to the map region, and only the clipped features are processed. This results in big speedups (more than a factor of 10) for small map regions with high-resolution coastlines and boundaries. These changes were motivated by the oceanographers (Eric and Rob Hetland) who often deal with quite small domains. There are a couple of downsides: 1) an external dependency on the GEOS lib (which is LGPL). I've included a copy of the source in svn, but there's still an extra ./configure; make; make install required. Eric and I searched high and low for a lighter weight, well-tested, BSD licensed solution, without much luck. General, robust polygon clipping is trickier than I thought. 2) more code paths through Pyrex C-extension code, increasing the probability of segfaults and bus errors. All in all, I think the speed gains and increased code readability are worth it. However, before I make a new release I'd appreciate any feedback. Are there build issues? (esp. on Windows, which I've not tested) Does it feel faster? Is the dependence on an LGPL'ed lib a problem? -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Speed improvements on the branch
Michael Droettboom wrote:
John Hunter wrote:
log_demo.py 1.769 2.011 0.242113%
Here is another area where there is an important difference. Panning
and zooming interactively with log scaling is much slower on the
branch, presumably because you have to redo the non-affine part every
time.
The non-affine part is not computed on every pan and zoom -- that was
one of the main design goals of the branch. (You can put a print
statement in Log10Transform.transform to see when it gets called.) I
can't feel a speed difference between the two, but...
Also, the old grid line bug on log plots seems to be back, as
evinced when you zoom from the "home" view.
...I should fix this bug first to have a fair comparison.
Fixing that bug actually had a net positive effect on the benchmarks
overall... (More correct *and* faster? Never happens.)
I created a benchmark using the middle plot of log_demo.py and moving
the bounds (just like simple_plot_fps.py) and I get the following:
Trunk: 23.68 fps
Branch: 16.83 fps
So there's definitely a slow down there. The profiler shows that a huge
chunk of the time is spent in numpy/core/ma.py, suggesting that masked
arrays are the culprit. I think further quarantining of masked arrays
will help -- for instance, a masked array is created whether or not
there are any values <= 0.0.
Any thoughts on this are welcome.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
#!/usr/bin/env python
"""
Example: simple line plot.
Show how to make and save a simple line plot with labels, title and grid
"""
from pylab import *
ion()
t = arange(0.001, 20.0+0.001, 0.001)
plot(t, sin(2*pi*t))
xlabel('time (s)')
ylabel('voltage (mV)')
title('About as simple as it gets, folks')
grid(True)
axes().set_xscale('log')
import time
frames = 100.0
t = time.time()
c = time.clock()
for i in xrange(int(frames)):
part = i / frames
axis([part * 20.0 + 0.001, part * 20.0 + 20.001, -1.0, 1.0])
wallclock = time.time() - t
user = time.clock() - c
print "wallclock:", wallclock
print "user:", user
print "fps:", frames / wallclock
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib: [4325] trunk/matplotlib/lib/matplotlib/axes.py
[EMAIL PROTECTED] wrote: > Revision: 4325 > http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev > Author: dsdale > Date: 2007-11-15 13:23:27 -0800 (Thu, 15 Nov 2007) > > Log Message: > --- > added npy.seterr(invalid='ignore') to beginning of axes.py, to silence > repeated warnings created by finding extrema of arrays containing nans > (discovered during calls to errorbar) Darren, Is this hiding a problem that will pop up farther down the line? I think the strategy so far has been that inputs to plotting functions should use masked arrays, not nans, and correspondingly, the plotting functions should handle masked arrays gracefully. Although nans are used at some internal stages, I don't think they are handled correctly from end to end. We could add nan checks at the early argument processing stage, but it would slow things down a bit. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib: [4325] trunk/matplotlib/lib/matplotlib/axes.py
On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote: > [EMAIL PROTECTED] wrote: > > Revision: 4325 > > > > http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev > > Author: dsdale > > Date: 2007-11-15 13:23:27 -0800 (Thu, 15 Nov 2007) > > > > Log Message: > > --- > > added npy.seterr(invalid='ignore') to beginning of axes.py, to silence > > repeated warnings created by finding extrema of arrays containing nans > > (discovered during calls to errorbar) > > Darren, > > Is this hiding a problem that will pop up farther down the line? I don't know, this problem was pretty well hidden to begin with. I consider it a bug that numpy doesnt gracefully handle finding the extrema of an array that containing nans. Why should this warrant a warning? > I think the strategy so far has been that inputs to plotting functions > should use masked arrays, not nans, and correspondingly, the plotting > functions should handle masked arrays gracefully. Although nans are > used at some internal stages, I don't think they are handled correctly > from end to end. We could add nan checks at the early argument > processing stage, but it would slow things down a bit. Do you mean that matplotlib does not support input that contains nans? Should the average user really have to care if they are passing input with nans in it? I think not. I must have misunderstood. Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib: [4325] trunk/matplotlib/lib/matplotlib/axes.py
Darren Dale wrote: > On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote: >> [EMAIL PROTECTED] wrote: >>> Revision: 4325 >>> >>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev >>> Author: dsdale >>> Date: 2007-11-15 13:23:27 -0800 (Thu, 15 Nov 2007) >>> >>> Log Message: >>> --- >>> added npy.seterr(invalid='ignore') to beginning of axes.py, to silence >>> repeated warnings created by finding extrema of arrays containing nans >>> (discovered during calls to errorbar) >> Darren, >> >> Is this hiding a problem that will pop up farther down the line? > > I don't know, this problem was pretty well hidden to begin with. I consider > it > a bug that numpy doesnt gracefully handle finding the extrema of an array > that containing nans. Why should this warrant a warning? There are major differences of opinion, or differences of application, as to how nans and other floating point oddities should be handled. As a result, numpy was designed to allow the user to specify how floating point exceptions should be handled. Matlab-style handling of nans--which I have always found enormously useful in Matlab--imposes a significant computational cost, and neither the style nor the cost is acceptable to a substantial fraction of the numpy community. Therefore numpy supplies nanmax and nanmin for the case where you want to ignore nans, and amax and amin for the case where a nan means something is wrong and you don't want to ignore the nan. (There are also nanargmax, nanargmin, and nansum.) > >> I think the strategy so far has been that inputs to plotting functions >> should use masked arrays, not nans, and correspondingly, the plotting >> functions should handle masked arrays gracefully. Although nans are >> used at some internal stages, I don't think they are handled correctly >> from end to end. We could add nan checks at the early argument >> processing stage, but it would slow things down a bit. > > Do you mean that matplotlib does not support input that contains nans? Should > the average user really have to care if they are passing input with nans in > it? I think not. I must have misunderstood. > I think that nans "do the right thing" in some places but not others; they have never been explicitly supported in plot function input. The design decision was to use masked arrays, which are more general, instead. I have thought about a possible alternative, in which masked arrays would be immediately converted to nan-filled arrays, and nans would be fully used and supported internally as well as in the interface. I never came to the conclusion that this was a good idea, though, because masked arrays have some advantages. Therefore I have been trying to improve masked array use and support in mpl and in numpy. Eric > Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
