matplotlib-devel Mailing List for matplotlib (Page 6)

On Friday 16 November 2007 04:23:41 pm Rob Hetland wrote:
> __version__ = '3.0.0b1'
>
>
> So, no version, rather __version__.
This is fixed in svn.
< traits-2: no version report (that I can find)
traits-2: version.version
traits-3: version.__version__
traits-4: stay tuned :)
Darren

On Friday 16 November 2007 01:46:25 pm Rob Hetland wrote:
> On Nov 16, 2007, at 6:10 PM, Darren Dale wrote:
> > Hi Rob,
> >
> > On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
> >> Some recent changes (in the last few days) have caused my build to
> >> break. Three things:
> >>
> >> First of all, the line in setupext.py: if version.version.endswith
> >> ('mpl'):
> >> fails. I can comment this block out, and set the return of
> >> check_provide_traits(): to True, and things seem to work well.
> >
> > I'm surprised by that failure, but need some more information to
> > fix it. What
> > is the type and value of version.version on your machine? What
> > specifically
> > did you block out to make it work?
>
> The exact error is:
>
> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
> configobj: matplotlib will provide
> Traceback (most recent call last):
> File "setup.py", line 234, in <module>
> if check_provide_traits(): build_traits(ext_modules, packages)
> File "/Users/rob/src/python/matplotlib/matplotlib/setupext.py",
> line 468, in check_provide_traits
> if version.version.endswith('mpl'):
> AttributeError: 'module' object has no attribute 'version'
>
> The problem is that my enthough.traits.version has no version attribute:
> >>> from enthought.traits import version
> >>> version.version
>
> ------------------------------------------------------------------------
> ---
> AttributeError Traceback (most recent call
> last)
>
> /Users/rob/<ipython console> in <module>()
>
> AttributeError: 'module' object has no attribute 'version'
Ok, it looks like I haven't covered all the possible variations in the traits 
API yet. What version of traits are you using? Would you send me a copy of 
your version.py file off list?
Thanks,
Darren

On Nov 16, 2007, at 6:10 PM, Darren Dale wrote:
> Hi Rob,
>
> On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
>> Some recent changes (in the last few days) have caused my build to
>> break. Three things:
>>
>> First of all, the line in setupext.py: if version.version.endswith
>> ('mpl'):
>> fails. I can comment this block out, and set the return of
>> check_provide_traits(): to True, and things seem to work well.
>
> I'm surprised by that failure, but need some more information to 
> fix it. What
> is the type and value of version.version on your machine? What 
> specifically
> did you block out to make it work?
>
The exact error is:
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: matplotlib will provide
Traceback (most recent call last):
 File "setup.py", line 234, in <module>
 if check_provide_traits(): build_traits(ext_modules, packages)
 File "/Users/rob/src/python/matplotlib/matplotlib/setupext.py", 
line 468, in check_provide_traits
 if version.version.endswith('mpl'):
AttributeError: 'module' object has no attribute 'version'
The problem is that my enthough.traits.version has no version attribute:
 >>> from enthought.traits import version
 >>> version.version
------------------------------------------------------------------------ 
---
AttributeError Traceback (most recent call 
last)
/Users/rob/<ipython console> in <module>()
AttributeError: 'module' object has no attribute 'version'
To make it work, I changed this:
def check_provide_traits():
 if options['provide_traits'] is True:
 print_status("enthought.traits", "matplotlib will provide")
 return True
 try:
 from enthought import traits
 try:
 from enthought.traits import version
 except:
 print_status("enthought.traits", "unknown and 
incompatible version: < 2.0")
 return False
 else:
 if version.version.endswith('mpl'):
 print_status("enthought.traits", "matplotlib will 
provide")
 return True
 else:
 print_status("enthought.traits", version.version)
 return False
 except ImportError:
 if options['provide_traits']:
 print_status("enthought.traits", "matplotlib will provide")
 return True
 else:
 print_status("enthought.traits", "no")
 return False
To this:
def check_provide_traits():
 if options['provide_traits'] is True:
 print_status("enthought.traits", "matplotlib will provide")
 return True
 try:
 from enthought import traits
 try:
 from enthought.traits import version
 except:
 print_status("enthought.traits", "unknown and 
incompatible version: < 2.0")
 return False
 else:
 # if version.version.endswith('mpl'):
 # print_status("enthought.traits", "matplotlib will 
provide")
 # return True
 # else:
 # print_status("enthought.traits", version.version)
 # return False
 return True
 except ImportError:
 if options['provide_traits']:
 print_status("enthought.traits", "matplotlib will provide")
 return True
 else:
 print_status("enthought.traits", "no")
 return False
I'm not sure if this is the _really_ right thing to do, but it does 
compile fine after this change, and I assume the answer (True) is the 
right one.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Darren Dale wrote:
> I think nan's and inf's are a fact of life. They sometimes pop up in my work, 
> and would prefer that matplotlib handle them properly. But I haven't 
> contributed much to the actual plotting functions and don't know much about 
> the advantages of masked arrays, so I'll defer to you.
Darren,
I would like to return to this. It may make good sense for us to use 
something like x=ma.masked_where(~npy.isfinite(x), x) at the outermost 
level of argument processing, in place of x = ma.asarray(x). It will 
add a few msec, which is OK if it is done once or a few times per plot. 
 It is not good if it happens hundreds of times per plot, though, so it 
is acceptable only if there is a clear separation between outer argument 
processing--the most public part of the API--and internal functions.
The method suggested above actually won't work with numpy.ma--only with 
 maskedarray.
I have to put this off for a while longer.
Eric

Hi Rob,
On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
> Some recent changes (in the last few days) have caused my build to
> break. Three things:
>
> First of all, the line in setupext.py: if version.version.endswith
> ('mpl'):
> fails. I can comment this block out, and set the return of
> check_provide_traits(): to True, and things seem to work well.
I'm surprised by that failure, but need some more information to fix it. What 
is the type and value of version.version on your machine? What specifically 
did you block out to make it work?
Thanks,
Darren

Some recent changes (in the last few days) have caused my build to 
break. Three things:
First of all, the line in setupext.py: if version.version.endswith 
('mpl'):
fails. I can comment this block out, and set the return of 
check_provide_traits(): to True, and things seem to work well.
Second, I get this error:
2007年11月16日 16:53:25.881 Python[6935] *** _NSAutoreleaseNoPool(): 
Object 0x18081c10 of class NSCarbonWindowContentView autoreleased 
with no pool in place - just leaking
when plotting text to the screen. I am using mathtext with the Arev 
Sans fonts.
Third, keypress events seem to be broken.
I am using Mac OS 10.4 with the TkAgg backend.
I'm sorry that I'm only posting problems and not posting more fixes, 
but I don't have enough time right now to track these things down at 
the moment, and wanted to get the word out quickly. Perhaps if there 
are still issues next week, I can check into these issues a bit more 
deeply.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Thursday 15 November 2007 08:51:11 pm Eric Firing wrote:
> Darren Dale wrote:
> > On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote:
> >> ds...@us... wrote:
> >>> Revision: 4325
> >>>
> >>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
> >>> Author: dsdale
> >>> Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
> >>>
> >>> 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.
I reverted my change this morning.
I think nan's and inf's are a fact of life. They sometimes pop up in my work, 
and would prefer that matplotlib handle them properly. But I haven't 
contributed much to the actual plotting functions and don't know much about 
the advantages of masked arrays, so I'll defer to you.
Darren

In any case, I think it's dangerous to set numpy's global error handling 
mode permanently. Is it feasible to do this on a need-to-protect basis 
by wrapping just the cases where this is needed with:
npy_orig_err = npy.seterr(invalid='ignore')
try:
 do_potentially_risky_stuff()
finally:
 npy.seterr(npy_orig_err)
Users might have code, for example, where ignoring this error will lead 
to bad consequences (including hard-to-find bugs).
-Andrew
Eric Firing wrote:
> ds...@us... wrote:
>> Revision: 4325
>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
>> Author: dsdale
>> Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
>>
>> 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/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Darren Dale wrote:
> On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote:
>> ds...@us... wrote:
>>> Revision: 4325
>>> 
>>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
>>> Author: dsdale
>>> Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
>>>
>>> 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

On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote:
> ds...@us... wrote:
> > Revision: 4325
> > 
> > http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
> > Author: dsdale
> > Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
> >
> > 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

ds...@us... wrote:
> Revision: 4325
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
> Author: dsdale
> Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
> 
> 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

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/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Michael Droettboom wrote:
> John Hunter wrote:
>>> log_demo.py 1.769 2.011 0.242 113%
>>
>> 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

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!")

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

John Hunter wrote:
> On Nov 15, 2007 1:51 PM, Michael Droettboom <md...@st...> 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

On Nov 15, 2007 1:51 PM, Michael Droettboom <md...@st...> 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

John Hunter wrote:
> On Nov 15, 2007 12:53 PM, Michael Droettboom <md...@st...> 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=10000; elapsed=0.133
> N=100000; elapsed=0.594
> N=1000000; elapsed=5.193
> 
> 
> Branch:
> N=10; elapsed=0.207
> N=100; elapsed=0.118
> N=1000; elapsed=0.138
> N=10000; elapsed=0.280
> N=100000; elapsed=1.671
> N=1000000; 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=10000; elapsed=0.067
N=100000; elapsed=0.326
N=1000000; elapsed=2.913
Branch:
N=10; elapsed=0.033
N=100; elapsed=0.028
N=1000; elapsed=0.030
N=10000; elapsed=0.055
N=100000; elapsed=0.310
N=1000000; 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.242 113%
> 
> 
> 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

On Nov 15, 2007 12:53 PM, Michael Droettboom <md...@st...> 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=10000; elapsed=0.133
N=100000; elapsed=0.594
N=1000000; elapsed=5.193
Branch:
N=10; elapsed=0.207
N=100; elapsed=0.118
N=1000; elapsed=0.138
N=10000; elapsed=0.280
N=100000; elapsed=1.671
N=1000000; elapsed=15.877
> log_demo.py 1.769 2.011 0.242 113%
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

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

On Nov 14, 2007 3:00 PM, Boyd Waters <bw...@nr...> wrote:
>
> On Nov 14, 2007, at 11:11 AM, Jeremy Conlin wrote:
>
> > Mr. Waters,
> >
> > I read on the matplotlib mailing lists that you have compiled
> > matplotlib on Leopard using libpng, freetype, etc. that are included
> > with Leopard. I am trying to do the same, but have so far been
> > unsuccessful. I could install those libraries from source, but would
> > rather not. Would you mind sharing what you did to compile matplotlib
> > with the included libraries?
>
>
> I did this with a MacPorts build system. It checks out the matplotlib
> from subversion, applies some patches, then builds.
>
> Ah, I built with Apple's pre-release GCC 4.2 for Leopard, which is
> available for ADC members... I have also built this with a "stock" GCC
> 4.2.1, so you might be able to just get that compiler. And almost
> certainly it would work with Apple's GCC 4.0, but you'll have to
> remove the CFLAGS settings (see below).
>
> Oh yes... I also didn't like the flags that Apple used to build
> Python; distutils has no way of overriding these and it breaks GCC
> 4.2.x. So I used a 'fake' gcc that strips off the offending flags and
> then calls the 'real' compiler:
>
> I used MacPorts to do all this. But here is a way that might work with
> a bash shell -- I'm just writing this down as an example, I haven't
> tested it, but this is sort of what I have in mind:
>
> ### ;;;;;;;;;;;;;;;;;;;;;;;;;;; cut here
>
> mkdir mpl-devel
> cd mpl-devel
>
> cat > gccflt-4.2 <<EOF
> #!/usr/bin/env python
>
> # test with this at the command line
> # ./gccflt-4.2 -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
>
> import sys
> import os
>
> realprog = "/usr/bin/gcc-4.2"
> options_to_remove = set(['-no-cpp-precomp', '-Wno-long-double',
> '-mno-fused-madd', '-faltivec',
> ])
>
> args = [a for a in sys.argv[1:] if a not in options_to_remove]
>
> args.insert(0, '-fno-strict-aliasing')
> print args
> os.execvp(realprog, [realprog] + args)
> EOF
>
>
> sed -e 's,gcc-4.2,g++-4.2' < gccflt > g++flt
>
> chmod +x gccflt
> chmod +x g++flt
>
> svn co http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
> -r '{2007年10月25日}'
> ;
> export CPPFLAGS=$(/usr/X11R6/bin/freetype-config --cflags)
> export LDFLAGS=$(/usr/X11R6/bin/freetype-config --libs )
> export ARCHFLAGS='-arch i386'
>
> cd matplotlib
>
> patch -p0 < ~/Desktop/patch-setupext.py
> patch -p0 < ~/Desktop/patch-stdc++
>
> python setup.py build
> python setup.pu install
>
>
> #;;;;;;;;;;;;;;;;;;;
> #================================= end shell script
>
>
>
> One of my targets is to make a "developer" build available - which
> means that my boss will be gently reminding me to provide this.
>
> I was granted commit permissions on MacPorts, but have so far failed
> to commit my things back upstream to them; before Leopard I had really
> torn up their Python modules so that everything is deployed in a
> single /opt/local... tree. (I didn't put things in /Library).
>
> With Leopard, if you want to use the system (Apple) Python, then I put
> things in /Library/Python/2.5/site-packages. I'm not sure that's the
> best thing to do. Initially it seems like no problem but we *always*
> run into conflicts, or want to have multiple versions available
> simultaneously...
> Hope this helps!
I'm sorry, but I couldn't get that shell script to work. I tried
copying everything between the "perforations" into a MPL.sh file.
Then I executed the file as
bash MPL.sh
That didn't work. I also tried making a Python file from the portion
that looks like Python code, but I couldn't get that to do anything
useful either.
Please forgive my ignorance :-!
>
> Oh, shoot... I didn't tell you how to build IPython with readline
> support... this email is too long already, but search the IPython dev
> list or I can send along a patch.
I would like a patch for this too, if you don't mind! IPython was my
next step after matplotlib.
Thanks a bunch,
Jeremy
>
> - boyd
>
> Boyd Waters
> http://www.aoc.nrao.edu/~bwaters
>
>
>
>
>
>
>

John Hunter wrote:
> On Nov 14, 2007 1:53 PM, Ryan May <rm...@ou...> wrote:
>> Hi,
>>
>> Is there any reason that circles are approximated by polygons when
>> written out by vector graphics backends (i.e. SVG, PS)? Someone pointed
>> this out to me, and having verified it, I found it surprising. I would
>> think since at least SVG directly supports circles, they'd be used for
>> output.
> 
> This has been fixed in mpl svn for Agg and PS and will be included in
> the next release, but not yet for SVG. In the "transforms" branch,
> all supported backends (including Agg, PS and SVG draw "true" circles,
> and the plan is to merge these changes into the main trunk sometime
> after the next release.
On the branch, circles are actually approximated using cubic bezier 
curves. These apparently have a maximum radial error of less than 1e-3, 
so should be indistinguishable to the naked eye. I suspect that many 
rendering engines (e.g. Acrobat Reader) draw circles that way anyway for 
efficiency. But you still won't see "circle" elements in the SVG files.
This distinction is only important when you try to edit or analyse the 
resulting files -- since they aren't "logical" circles, a vector editor 
(e.g. inkscape), won't edit them as circles, but as paths. But since 
post-editing matplotlib plots is kind of problematic in a number of 
other ways, I don't know if that's a real problem.
(The point of all this is to reduce the number of required drawing 
commands in the backends to the lowest common denominator. You can draw 
virtually anything (with reasonable approximation) with polycurves, so 
that is now the only drawing primitive that mpl will ever output.)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 14, 2007 1:53 PM, Ryan May <rm...@ou...> wrote:
> Hi,
>
> Is there any reason that circles are approximated by polygons when
> written out by vector graphics backends (i.e. SVG, PS)? Someone pointed
> this out to me, and having verified it, I found it surprising. I would
> think since at least SVG directly supports circles, they'd be used for
> output.
This has been fixed in mpl svn for Agg and PS and will be included in
the next release, but not yet for SVG. In the "transforms" branch,
all supported backends (including Agg, PS and SVG draw "true" circles,
and the plan is to merge these changes into the main trunk sometime
after the next release.
JDH

On Nov 14, 2007, at 11:11 AM, Jeremy Conlin wrote:
> Mr. Waters,
>
> I read on the matplotlib mailing lists that you have compiled
> matplotlib on Leopard using libpng, freetype, etc. that are included
> with Leopard. I am trying to do the same, but have so far been
> unsuccessful. I could install those libraries from source, but would
> rather not. Would you mind sharing what you did to compile matplotlib
> with the included libraries?
I did this with a MacPorts build system. It checks out the matplotlib 
from subversion, applies some patches, then builds.
Ah, I built with Apple's pre-release GCC 4.2 for Leopard, which is 
available for ADC members... I have also built this with a "stock" GCC 
4.2.1, so you might be able to just get that compiler. And almost 
certainly it would work with Apple's GCC 4.0, but you'll have to 
remove the CFLAGS settings (see below).
Oh yes... I also didn't like the flags that Apple used to build 
Python; distutils has no way of overriding these and it breaks GCC 
4.2.x. So I used a 'fake' gcc that strips off the offending flags and 
then calls the 'real' compiler:
I used MacPorts to do all this. But here is a way that might work with 
a bash shell -- I'm just writing this down as an example, I haven't 
tested it, but this is sort of what I have in mind:
### ;;;;;;;;;;;;;;;;;;;;;;;;;;; cut here
mkdir mpl-devel
cd mpl-devel
cat > gccflt-4.2 <<EOF
#!/usr/bin/env python
# test with this at the command line
# ./gccflt-4.2 -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
import sys
import os
realprog = "/usr/bin/gcc-4.2"
options_to_remove = set(['-no-cpp-precomp', '-Wno-long-double',
 '-mno-fused-madd', '-faltivec',
 ])
args = [a for a in sys.argv[1:] if a not in options_to_remove]
args.insert(0, '-fno-strict-aliasing')
print args
os.execvp(realprog, [realprog] + args)
EOF
sed -e 's,gcc-4.2,g++-4.2' < gccflt > g++flt
chmod +x gccflt
chmod +x g++flt
svn co http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib 
 -r '{2007年10月25日}'
;
export CPPFLAGS=$(/usr/X11R6/bin/freetype-config --cflags)
export LDFLAGS=$(/usr/X11R6/bin/freetype-config --libs )
export ARCHFLAGS='-arch i386'
cd matplotlib
patch -p0 < ~/Desktop/patch-setupext.py
patch -p0 < ~/Desktop/patch-stdc++
python setup.py build
python setup.pu install
#;;;;;;;;;;;;;;;;;;;
#================================= end shell script
One of my targets is to make a "developer" build available - which 
means that my boss will be gently reminding me to provide this.
I was granted commit permissions on MacPorts, but have so far failed 
to commit my things back upstream to them; before Leopard I had really 
torn up their Python modules so that everything is deployed in a 
single /opt/local... tree. (I didn't put things in /Library).
With Leopard, if you want to use the system (Apple) Python, then I put 
things in /Library/Python/2.5/site-packages. I'm not sure that's the 
best thing to do. Initially it seems like no problem but we *always* 
run into conflicts, or want to have multiple versions available 
simultaneously...

Hi,
Is there any reason that circles are approximated by polygons when 
written out by vector graphics backends (i.e. SVG, PS)? Someone pointed 
this out to me, and having verified it, I found it surprising. I would 
think since at least SVG directly supports circles, they'd be used for 
output.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma