matplotlib-users Mailing List for matplotlib

Hi folks-
I'd like to report a possible way for OS X mpl users to use Apple's freetype2
(in their X11), to see if there are any problems with it I may need to be
aware of, and if not, to offer it as a possible solution to others installing
mpl from source on OS X. I know Apple's freetype2 was "broken" in Panther,
but it's possible things are different with Tiger.
The basic issue is that Apple's X11 installs a version of freetype2 under
/usr/X11R6/ which might be usable by mpl, and which can conflict with other
copies users might install to build mpl.
With Panther (10.3), I followed mpl build instructions and installed my own
freetype2. I tried two different methods: using i-Installer, and directly
from source (into /usr/local/). Both approaches worked fine with mpl.
However, using either version led to problems with other X11 software I tried
to install. The issues I remember had to do with GTK (i.e., installing PyGTK
and an unrelated GTK app, geda, from source). There were troublesome issues
having to do with freetype2 and some other X11 libs. According to some
anecdotal reports I found online, it appears Apple did something strange to
the freetype version (at least in Panther versions of X11), so gcc/ld would
link against it even if a more recent version was in /usr/local/, but then
there would be freetype issues at runtime. My eventual solution involved
removing various parts of Apple's X11, and putting links in /usr/X11R6/ to the
new installs in /usr/local/. (I have a script to do this, if anyone needs
it.)
This was such a headache that when I just upgraded to Tiger (10.4; a clean
install), I thought I'd see if mpl could be installed using the new freetype2 
in Apple's X11. (I also did not install zlib, since 10.4 includes it in
/usr/lib/.) To do so, I had to modify "add_ft2font_flags" in setupext.py,
adding this to the top:
 # Added to provide access to Apple's freetype2 when their X11 is installed
 if sys.platform=='darwin':
 # Add paths to Apple's X11R6.
 module.library_dirs.extend(
 ['/usr/X11R6/lib'])
 module.include_dirs.extend(
 ['/usr/X11R6/include'])
(Also, the docstring is incorrect and should be fixed to refer to freetype2
rather than gd.) With this change, mpl built without any errors, and as far
as I can tell so far, is working just fine. I've come across a few missing
font/font replacement warnings, but I don't know whether installing a new
freetype2 would have avoided these.
If anyone can see a problem with this procedure, please let me know.
Otherwise, it means that Tiger users who have installed Apple's X11 need to
install just one library (libpng) before installing mpl, so long as the above
change is made to setupext.py. I don't know if the change would have any
ramifications for those who don't install X11 or who do install it and *also*
install freetype2 in /usr/local/. If no problems are anticipated, perhaps
the change can be incorporated into mpl.
Thanks for any feedback on this.
-Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

>>>>> "Jeff" == Jeff Huang <hu...@ui...> writes:
 Jeff> Is it possible to have gradients in the bar graphs made by
 Jeff> matplotlib? I couldn't find anything about it in the user
 Jeff> guide.
Here is some example code form the mailing list
To: Christopher Barker <Chr...@no...>
Cc: mat...@li...
Subject: Re: [Matplotlib-users] graphs
From: John Hunter <jdh...@ac...>
Date: 2006年5月16日 15:01:15 -0500
>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:
 Christopher> That I don't know. The Agg renderer certainly can do
 Christopher> a nice job with gradients, but I don't know if MPL
 Christopher> support that.
You can emulate gradients using matplotlib images -- either with colormaps or
defining your own rgba endpoints for the gradients. Here's an example
of an axes background gradient
 from pylab import figure, show, nx, cm
 fig = figure()
 xmin, xmax = xlim = 0,2
 ymin, ymax = ylim = -1,1
 ax = fig.add_subplot(111, xlim=xlim, ylim=ylim,
 autoscale_on=False)
 X = [[.6, .6],[.7,.7]]
 ax.imshow(X, interpolation='bicubic', cmap=cm.Blues,
 extent=(xmin, xmax, ymin, ymax), alpha=1)
 t = nx.arange(xmin, xmax,0.01)
 ax.plot(t, nx.sin(2*nx.pi*t), lw=2, color='black')
 show()
Likewise, you can make your own gradient bars charts:
 from pylab import figure, show, nx, cm
 def gbar(ax, x, y, width=0.5, bottom=0):
 X = [[.6, .6],[.7,.7]]
 for left,top in zip(x, y):
 right = left+width
 ax.imshow(X, interpolation='bicubic', cmap=cm.Blues,
 extent=(left, right, bottom, top), alpha=1)
 fig = figure()
 xmin, xmax = xlim = 0,10
 ymin, ymax = ylim = 0,1
 ax = fig.add_subplot(111, xlim=xlim, ylim=ylim,
 autoscale_on=False)
 X = [[.6, .6],[.7,.7]]
 ax.imshow(X, interpolation='bicubic', cmap=cm.copper,
 extent=(xmin, xmax, ymin, ymax), alpha=1)
 N = 10
 x = nx.arange(N)+0.25
 y = nx.mlab.rand(N)
 gbar(ax, x, y, width=0.7)
 ax.set_aspect('normal')
 show()
Viewer discretion is advised.
If you want to get clever, you can define patterns and fills this way
too. We should add an interface to expose this functionality more
readily...
JDH
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Is it possible to have gradients in the bar graphs made by matplotlib? I
couldn't find anything about it in the user guide.
Thanks
Jeff

Pierre,
Offhand, it looks like it should go into ticker.py, so I will probably 
do that.
Eric
Pierre GM wrote:
> On Monday 18 December 2006 13:29, David L Goldsmith wrote:
>> Simson Garfinkel wrote:
>>> It really depends on your audience as to whether or not 1,000,000
>>> through 9,000,000 is better displayed in scientific notation or not.
>>> For audiences that I frequently present to, any scientific notation
>>> is just unacceptable. You can add quantifiers (like KBps, MBps,
>>> GBps), but presenting something a 5e+5 Bps will just be lost. You
>>> *might* get away with e+3, e+6, and e+9, but never the other e's.
>> Ah, "Engineering" notation - that could be a useful helper function.
> 
> A few months ago the question got asked on this very list. 
> The idea is to define a specific formatter. Here's what I'd come with (I copy 
> the initial post for convenience at the end of the message).
> 
> If it's found useful, I could put it in the cookbook (now that I remember how 
> to edit the wiki). Or I could leave our dear developers add it to the core.
> 
> 
> P.
> 
> #----------------------------------------------
> 
> class EngrFormatter(ScalarFormatter):
> """A variation of the standard ScalarFormatter, using only multiples of 
> three
> in the mantissa. A fixed number of decimals can be displayed with the optional 
> parameter `ndec` . If `ndec` is None (default), the number of decimals is 
> defined
> from the current ticks.
> """
> def __init__(self, ndec=None, useOffset=True, useMathText=False):
> ScalarFormatter.__init__(self, useOffset, useMathText)
> if ndec is None or ndec < 0:
> self.format = None
> elif ndec == 0:
> self.format = "%d"
> else:
> self.format = "%%1.%if" % ndec
> #........................
> def _set_orderOfMagnitude(self, mrange):
> """Sets the order of margnitude.""" 
> locs = N.absolute(self.locs)
> if self.offset: 
> oom = math.floor(math.log10(mrange))
> else:
> if locs[0] > locs[-1]: 
> val = locs[0]
> else: 
> val = locs[-1]
> if val == 0: 
> oom = 0
> else: 
> oom = math.floor(math.log10(val))
> if oom <= -3:
> self.orderOfMagnitude = 3*(oom//3)
> elif oom <= -1:
> self.orderOfMagnitude = -3
> elif oom >= 4:
> self.orderOfMagnitude = 3*(oom//3)
> else:
> self.orderOfMagnitude = 0
> #........................
> def _set_format(self):
> """Sets the format string to format all ticklabels."""
> # set the format string to format all the ticklabels
> locs = (N.array(self.locs)-self.offset) / 10**self.orderOfMagnitude + 
> 1e-15
> sigfigs = [len(str('%1.3f'% loc).split('.')[1].rstrip('0')) \
> for loc in locs]
> sigfigs.sort()
> if self.format is None:
> self.format = '%1.' + str(sigfigs[-1]) + 'f'
> if self._usetex or self._useMathText: 
> self.format = '$%s$' % self.format
> #..............................................................................
> class MinimalFormatter(Formatter):
> """A minimal formatter: just the plain data !"""
> def __init__(self,sigfigs=None):
> if sigfigs is None:
> self.fmt = "%f"
> else:
> self.fmt = "%.%if" % sigfigs
> def __call__(self,x,pos=None):
> return str(self.fmt % x).rstrip('0')
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Monday 18 December 2006 13:29, David L Goldsmith wrote:
> Simson Garfinkel wrote:
> > It really depends on your audience as to whether or not 1,000,000
> > through 9,000,000 is better displayed in scientific notation or not.
> > For audiences that I frequently present to, any scientific notation
> > is just unacceptable. You can add quantifiers (like KBps, MBps,
> > GBps), but presenting something a 5e+5 Bps will just be lost. You
> > *might* get away with e+3, e+6, and e+9, but never the other e's.
>
> Ah, "Engineering" notation - that could be a useful helper function.
A few months ago the question got asked on this very list. 
The idea is to define a specific formatter. Here's what I'd come with (I copy 
the initial post for convenience at the end of the message).
If it's found useful, I could put it in the cookbook (now that I remember how 
to edit the wiki). Or I could leave our dear developers add it to the core.
P.
#----------------------------------------------
class EngrFormatter(ScalarFormatter):
 """A variation of the standard ScalarFormatter, using only multiples of 
three
in the mantissa. A fixed number of decimals can be displayed with the optional 
parameter `ndec` . If `ndec` is None (default), the number of decimals is 
defined
from the current ticks.
 """
 def __init__(self, ndec=None, useOffset=True, useMathText=False):
 ScalarFormatter.__init__(self, useOffset, useMathText)
 if ndec is None or ndec < 0:
 self.format = None
 elif ndec == 0:
 self.format = "%d"
 else:
 self.format = "%%1.%if" % ndec
 #........................
 def _set_orderOfMagnitude(self, mrange):
 """Sets the order of margnitude.""" 
 locs = N.absolute(self.locs)
 if self.offset: 
 oom = math.floor(math.log10(mrange))
 else:
 if locs[0] > locs[-1]: 
 val = locs[0]
 else: 
 val = locs[-1]
 if val == 0: 
 oom = 0
 else: 
 oom = math.floor(math.log10(val))
 if oom <= -3:
 self.orderOfMagnitude = 3*(oom//3)
 elif oom <= -1:
 self.orderOfMagnitude = -3
 elif oom >= 4:
 self.orderOfMagnitude = 3*(oom//3)
 else:
 self.orderOfMagnitude = 0
 #........................
 def _set_format(self):
 """Sets the format string to format all ticklabels."""
 # set the format string to format all the ticklabels
 locs = (N.array(self.locs)-self.offset) / 10**self.orderOfMagnitude + 
1e-15
 sigfigs = [len(str('%1.3f'% loc).split('.')[1].rstrip('0')) \
 for loc in locs]
 sigfigs.sort()
 if self.format is None:
 self.format = '%1.' + str(sigfigs[-1]) + 'f'
 if self._usetex or self._useMathText: 
 self.format = '$%s$' % self.format
#..............................................................................
class MinimalFormatter(Formatter):
 """A minimal formatter: just the plain data !"""
 def __init__(self,sigfigs=None):
 if sigfigs is None:
 self.fmt = "%f"
 else:
 self.fmt = "%.%if" % sigfigs
 def __call__(self,x,pos=None):
 return str(self.fmt % x).rstrip('0')

Simson Garfinkel wrote:
> Well, I come from the United States, where we basically ignore 
> international standards and let the rest of the world do what it 
> wants. Except when it annoys us.
> 
Insert wink or smiley face here to signify irony, yes?
> However, there is something called an internationalization which 
> tells clever programmers who use it what to use as a digits separator 
> and what to use as a decimal point. Support for I18N is built into 
> most operating systems. Unfortunately, I don' t know the Python API. 
> Does anybody?
>
> On Dec 18, 2006, at 10:35 AM, John Travers wrote:
>
> 
>> On 18/12/06, Simson Garfinkel <si...@ac...> wrote:
>> 
>>> It really depends on your audience as to whether or not 1,000,000
>>> through 9,000,000 is better displayed in scientific notation or not.
>>> For audiences that I frequently present to, any scientific notation
>>> is just unacceptable. You can add quantifiers (like KBps, MBps,
>>> GBps), but presenting something a 5e+5 Bps will just be lost. You
>>> *might* get away with e+3, e+6, and e+9, but never the other e's.
>>> 
>> Where I come from (Europe) 9,000,000 means 9.0 and 9.000.000 means
>> what you mean. That is why there is an international standard of
>> having 9 000 000. Basically these things should be tunable through
>> simple rc options.
>> As to the point that different rc options can produce different
>> results on different machines, as far as I am aware, all options can
>> be overridden in the script itself (correct me if I am wrong?).
>>
>> Best regards,
>> John
>>
>> ---------------------------------------------------------------------- 
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to 
>> share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>> 
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>

yardbird wrote:
> On Saturday 16 December 2006 19:42, Xavier Gnata wrote:
>> Each time I'm working on C++ codes using vector or valarray, I would
>> like to be able to plot them.
> you should really check out the Boost::Python libraries. They allow you, among 
> other things, to expose your C++ container classes as python objects. I'm 
> using them heavily in my project and I'm very satisfied.
What this means is that you'd be using python to drive your C++ code, 
rather than using C++ code to drive a python/mpl code. In addition to 
Boost::Python, there are some other options to consider:
pyrex, Cxx, SWIG.
The other option is to use your C++ code to drive Python. This can be 
done by embedding a python interpreter in your C++ app. See the 
odfficial pyhton docs, and lots of other stuff online.
You also might want to check out Elmer:
http://elmer.sourceforge.net/
I've never used it, but it looks pretty cool. It's a tool that provides 
the infrastructure for calling python from C/C++.
Honestly, though, I'd go with the first approach -- drive your C++ code 
from Python -- I think that in addition to making it easy to plot 
results, etc, you'll be able to write unit tests, etc in python, and 
even get a full scripting engine, which could turn out to be very useful..
-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...

Simson Garfinkel wrote:
> It really depends on your audience as to whether or not 1,000,000 
> through 9,000,000 is better displayed in scientific notation or not. 
> For audiences that I frequently present to, any scientific notation 
> is just unacceptable. You can add quantifiers (like KBps, MBps, 
> GBps), but presenting something a 5e+5 Bps will just be lost. You 
> *might* get away with e+3, e+6, and e+9, but never the other e's.
> 
Ah, "Engineering" notation - that could be a useful helper function.
DG
>
> On Dec 18, 2006, at 8:53 AM, Darren Dale wrote:
>
> 
>> On Saturday 16 December 2006 20:00, Simson Garfinkel wrote:
>> 
>>> 1. I think that scientific notation should not be the default, unless
>>> numbers exceed 1E+7.
>>> 
>> There are good reasons to use scientific notation for smaller 
>> numbers than
>> 10e+-7: We dont want neighboring tick labels to run into each other 
>> on the x
>> axis, and we dont tick labels to run out of the window on the y 
>> axis. For
>> examples, see the attachments at the bottom of this page:
>> http://sourceforge.net/tracker/index.php? 
>> func=detail&aid=1196027&group_id=80706&atid=560720
>>
>> Darren
>>
>> 
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>

I wonder: how hard would it be to add some intelligence to the 
interpreter and/or exception handler such that if the manner of (mis)use 
of one of these implied that what the programmer meant was the other, 
then the error message would say something like "Perhaps you meant to 
use axis (or axes, as appropriate) here?"
DG
belinda thom wrote:
> On Dec 16, 2006, at 8:10 PM, John Hunter wrote:
>
> 
>> Simson> 3. If I was going to make a major change to the API at
>> Simson> this point, it would be to make it so that you don't have
>> Simson> a class/function/ identifier called "axes" and another one
>> Simson> called "axis." I frequently get confused between these two
>> Simson> words; I imagine that non-native English speakers get
>> Simson> confused even more frequently. Irregular noun plurals in
>> Simson> English are confusing, and it probably isn't necessary to
>> Simson> use both. One approach would be to never allow "axis," to
>> Simson> only allow "xaxis" and "yaxis" and perhaps something
>> Simson> (either_axis?) for the abstract super-class, but this may
>> Simson> be a bigger change than you wish to consider at the
>> Simson> present time.
>>
>> Yes, this is a confusing and poor nomenclature. We're probably stuck
>> with it at this point, since it fairly deeply ingrained.
>> 
>
> The axis/axes function names are Matlab relics, so to have used 
> something else would probably have caused other complaints.
>
> On the bright side, at least w/matplotlib, you're not paying out the 
> wazoo :-) for such things.
>
> --b
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>

Well, I come from the United States, where we basically ignore 
international standards and let the rest of the world do what it 
wants. Except when it annoys us.
However, there is something called an internationalization which 
tells clever programmers who use it what to use as a digits separator 
and what to use as a decimal point. Support for I18N is built into 
most operating systems. Unfortunately, I don' t know the Python API. 
Does anybody?
On Dec 18, 2006, at 10:35 AM, John Travers wrote:
> On 18/12/06, Simson Garfinkel <si...@ac...> wrote:
>> It really depends on your audience as to whether or not 1,000,000
>> through 9,000,000 is better displayed in scientific notation or not.
>> For audiences that I frequently present to, any scientific notation
>> is just unacceptable. You can add quantifiers (like KBps, MBps,
>> GBps), but presenting something a 5e+5 Bps will just be lost. You
>> *might* get away with e+3, e+6, and e+9, but never the other e's.
>
> Where I come from (Europe) 9,000,000 means 9.0 and 9.000.000 means
> what you mean. That is why there is an international standard of
> having 9 000 000. Basically these things should be tunable through
> simple rc options.
> As to the point that different rc options can produce different
> results on different machines, as far as I am aware, all options can
> be overridden in the script itself (correct me if I am wrong?).
>
> Best regards,
> John
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to 
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Sunday 17 December 2006 20:06, Eric Firing wrote:
> John Hunter wrote:
> [...]
>
> > Simson> To answer Eric's most recent posting:
> >
> > Simson> 1. I think that scientific notation should not be the
> > Simson> default, unless numbers exceed 1E+7.
> >
> > I agree with this -- scientific notation kicks in too soon IMO. I
> > think an rc setting would be fine. I am not adverse to more rc
> > settings personally. I haven't seen too many problems arising from
> > having a lot of rc settings.
>
> I have added an rc setting called axes.formatter.limits and set the
> defaults to -7, 7, so that now scientific notation starts at 1e+-7. This
> may be too large for some tastes--but at least now it is configurable.
> Maybe other users will comment on what they think the defaults should
> be. I don't have a strong opinion.
I think think the name for this rc setting could be improved. How about:
(x,y)tick.scientific_notation.threshold
or
axes.scientific_notation.threshold
> I also added a convenience method to the Axes class (called
> ticklabel_format())to make it easier to turn scientific notation on or
> off on either or both axes, with the idea that other formatting control
> might be added to the method later. I have not made the method a pylab
> function yet; I would rather wait until it settles down and people have
> had a chance to request a different name or turn thumbs down on the
> whole thing or whatever.
>
> Suggestions for better names or other aspects of these API additions are
> welcome. 
Something like use_scientific_notation() would be much clearer, in my opinion.

On 18/12/06, Simson Garfinkel <si...@ac...> wrote:
> It really depends on your audience as to whether or not 1,000,000
> through 9,000,000 is better displayed in scientific notation or not.
> For audiences that I frequently present to, any scientific notation
> is just unacceptable. You can add quantifiers (like KBps, MBps,
> GBps), but presenting something a 5e+5 Bps will just be lost. You
> *might* get away with e+3, e+6, and e+9, but never the other e's.
Where I come from (Europe) 9,000,000 means 9.0 and 9.000.000 means
what you mean. That is why there is an international standard of
having 9 000 000. Basically these things should be tunable through
simple rc options.
As to the point that different rc options can produce different
results on different machines, as far as I am aware, all options can
be overridden in the script itself (correct me if I am wrong?).
Best regards,
John

On Saturday 16 December 2006 19:42, Xavier Gnata wrote:
> Hi,
>
> Each time I'm working on C++ codes using vector or valarray, I would
> like to be able to plot them.
> The problem is that there is no straitforward way to do that in C++.
> My goal is not to code a QT or GTK application but only to be able to
> plot 1D and 2D things from one given large C++ code without having to
> add lots of lines of codes in my code (let say it is intend to be used
> in debug phase).
>
> Questions :
> Is there a way to call pylab plot and imshow from a C++ code ?
> In this case, I do not care if we have to copy the array and it can be
> slow. It would be a so nice feature to debug C++ image processing codes.
> Any example of code is welcome even they are not calling matplotlib but
> anthing else in python.
>
> Xavier.
> ps : In my codes, 2D images are stored as in a class derived from
> valarray (1D array) adding the size of the image along the 2 directions
> as private members.
Hi Xavier,
you should really check out the Boost::Python libraries. They allow you, among 
other things, to expose your C++ container classes as python objects. I'm 
using them heavily in my project and I'm very satisfied. Check them out here:
http://www.boost.org/libs/python/doc/
HTH,
 Francesco

It really depends on your audience as to whether or not 1,000,000 
through 9,000,000 is better displayed in scientific notation or not. 
For audiences that I frequently present to, any scientific notation 
is just unacceptable. You can add quantifiers (like KBps, MBps, 
GBps), but presenting something a 5e+5 Bps will just be lost. You 
*might* get away with e+3, e+6, and e+9, but never the other e's.
On Dec 18, 2006, at 8:53 AM, Darren Dale wrote:
> On Saturday 16 December 2006 20:00, Simson Garfinkel wrote:
>> 1. I think that scientific notation should not be the default, unless
>> numbers exceed 1E+7.
>
> There are good reasons to use scientific notation for smaller 
> numbers than
> 10e+-7: We dont want neighboring tick labels to run into each other 
> on the x
> axis, and we dont tick labels to run out of the window on the y 
> axis. For
> examples, see the attachments at the bottom of this page:
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1196027&group_id=80706&atid=560720
>
> Darren
>

On Saturday 16 December 2006 20:00, Simson Garfinkel wrote:
> 1. I think that scientific notation should not be the default, unless
> numbers exceed 1E+7.
There are good reasons to use scientific notation for smaller numbers than 
10e+-7: We dont want neighboring tick labels to run into each other on the x 
axis, and we dont tick labels to run out of the window on the y axis. For 
examples, see the attachments at the bottom of this page: 
http://sourceforge.net/tracker/index.php?func=detail&aid=1196027&group_id=80706&atid=560720
Darren

Eric Firing wrote:
>
> There is a clip function in all three numeric packages, so a native 
> clip is being used.
>
> If numpy.clip is actually slower than your version, that sounds like a 
> problem with the implementation in numpy. By all logic a single clip 
> function should either be the same (if it is implemented like yours) 
> or faster (if it is a single loop in C-code, as I would expect). This 
> warrants a little more investigation before changing the mpl code. 
> The best thing would be if you could make a simple standalone numpy 
> test case profiling both versions and post the results as a question 
> to the numpy-discussion list. Many such questions in the past have 
> resulted in big speedups in numpy.
I am much more familiar with internal numpy code than matplotlib's, so 
this is much easier for me, too :)
>
> One more thought: it is possible that the difference is because myclip 
> operates on the array in place while clip generates a new array. If 
> this is the cause of the difference then changing your last line to 
> "return a.copy()" probably would slow it down to the numpy clip speed 
> or slower.
It would be scary if a copy of a 8008x256 array of double took 100 ms... 
Fortunately, it does not, this does not seem to be the problem.
cheers,
David

David Cournapeau wrote:
[...]
> Ok, I've installed last svn, and now, there is still one function which 
> is much slower than a direct numpy implementation, so I would like to 
> know if this is inherent to the multiple backend nature of matplotlib or 
> not. The functor Normalize uses the clip function, and a direct numpy 
> would be 3 times faster (giving the show call a 20 % speed in my really 
> limited benchmarks):
> 
> if clip:
> mask = ma.getmask(val)
> #val = ma.array(nx.clip(val.filled(vmax), vmin, vmax),
> # mask=mask)
> def myclip(a, m, M):
> a[a<m] = m
> a[a>M] = M
> return a
> val = ma.array(myclip(val.filled(vmax), vmin, vmax), mask=mask)
> 
> I am a bit lost in the matplotlib code to see where clip is implemented 
> (is it in numerix and as such using the numpy function clip ?).
There is a clip function in all three numeric packages, so a native clip 
is being used.
If numpy.clip is actually slower than your version, that sounds like a 
problem with the implementation in numpy. By all logic a single clip 
function should either be the same (if it is implemented like yours) or 
faster (if it is a single loop in C-code, as I would expect). This 
warrants a little more investigation before changing the mpl code. The 
best thing would be if you could make a simple standalone numpy test 
case profiling both versions and post the results as a question to the 
numpy-discussion list. Many such questions in the past have resulted in 
big speedups in numpy.
One more thought: it is possible that the difference is because myclip 
operates on the array in place while clip generates a new array. If 
this is the cause of the difference then changing your last line to 
"return a.copy()" probably would slow it down to the numpy clip speed 
or slower.
Eric

Eric Firing wrote:
> David,
>
> I have made some changes in svn that address all but one of the points 
> you made:
>
> [....]
>> if self.clip:
>> mask = ma.getmaskorNone(val)
>> if mask == None:
>> val = ma.array(clip(val.filled(vmax), vmin, vmax))
>> else:
>> val = ma.array(clip(val.filled(vmax), vmin, vmax),
>> mask=mask)
>
> The real problem here is that I should not have been using 
> getmaskorNone(). In numpy.ma, we need nomask, not None, so we want an 
> ordinary getmask() call. ma.array(...., mask=ma.nomask) is very fast, 
> so the problem goes away.
>
>>
>> Actually, the problem is in ma.array: with a value of mask to None, 
>> it should not make a difference between mask = None or no mask arg, 
>> right ? 
> But it does, because for numpy it needs to be nomask; it does 
> something with None, but whatever it is, it is very slow.
>
>> I didn't change ma.array to keep my change as local as possible. To 
>> change only this operation as above gives a speed up from 1.8 s to ~ 
>> 1.0 s for to_rgba, which means calling show goes from ~ 2.2 s to ~1.4 
>> s. I also changed result = (val-vmin)/float(vmax-vmin)
>>
>> to
>>
>> invcache = 1.0 / (vmax - vmin)
>> result = (val-vmin) * invcache
>
> This is the one I did not address. I don't understand how this could 
> be making much difference, and some testing using ipython and %prun 
> with 1-line operations showed little difference with variations on 
> this theme. The fastest would appear to be (and logically should be, 
> I think) result = (val-vmin)*(1.0/(vmax-vmin)), but I don't think it 
> makes much difference--it looks to me like maybe 10-20 msec, not 100, 
> on my Pentium M 1.6 Ghz. Maybe still worthwhile, so I may yet make 
> the change after more careful testing.
>
>
>>
>> which gives a moderate speed up (around 100 ms for a 8000x256 points 
>> array). Once you make both those changes, the clip call is by far the 
>> most expensive operation in normalize functor, but the functor is not 
>> really expensive anymore compared to the rest, so this is not where I 
>> looked at.
>>
>> For the where calls in Colormap functor, I was wondering if they are 
>> necessary in all cases: some of those calls seem redundant, and it 
>> may be possible to detect that before calling them. This should be 
>> both easier and faster, at least in this case, than having a fast 
>> where ?
>>
>
> You hit the nail squarely: where() is the wrong function to use, and I 
> have eliminated it from colors.py. The much faster replacement is 
> putmask, which does as well as direct indexing with a Boolean but 
> works with all three numerical packages. I think that using the fast 
> putmask is better than trying to figure out special cases in which 
> there would be nothing to put, although I could be convinced otherwise.
>
>
>> I understand that support of multiple array backend, support of mask 
>> arrays have cost consequences. But it looks like it may be possible 
>> to speed things up for cases where an array has only meaningful 
>> values/no mask.
>
> The big gains here were essentially bug fixes--picking the appropriate 
> function (getmask versus getmaskorNone and putmask versus where).
Ok, I've installed last svn, and now, there is still one function which 
is much slower than a direct numpy implementation, so I would like to 
know if this is inherent to the multiple backend nature of matplotlib or 
not. The functor Normalize uses the clip function, and a direct numpy 
would be 3 times faster (giving the show call a 20 % speed in my really 
limited benchmarks):
if clip:
 mask = ma.getmask(val)
 #val = ma.array(nx.clip(val.filled(vmax), vmin, vmax),
 # mask=mask)
 def myclip(a, m, M):
 a[a<m] = m
 a[a>M] = M
 return a
 val = ma.array(myclip(val.filled(vmax), vmin, vmax), mask=mask)
I am a bit lost in the matplotlib code to see where clip is implemented 
(is it in numerix and as such using the numpy function clip ?).
Still, I must confess that all this looks quite good, because it was 
possible to speed things up quite considerably without too much effort,
cheers,
David

Hello,
I manage to use WXAgg backend by replacing 'TkAgg' with 'WXAgg' inside
matplotlibrc file.
I found that using this wx backend the figure size is smaller than using
TkAgg backend (the default size).
I try to make small experiment by resizing the figure.figsize inside
matplotlibrc file and found that using wx backend the figure size can not be
resized. Using TkAgg works fine.
Is this a bug ?
Sincerely Yours,
Pujo

shu...@16... wrote:
>> Shu: I'd make a mask by finding the points on the grid that are outside 
>> your polygon. Then use that mask to create a masked array from your 
>> data (masking the points you don't want to plot). matplotlib's contourf 
>> knows how to deal with masked arrays (at least when the masked region 
>> isn't too complicated). The basemap toolkit can plot data on map 
>> projections with coastlines and political boundaries (as in the PyNGL 
>> example you forwarded).
>>
>> -Jeff
>> 
>
> Thanks Jeff.Following your advice I have successed to get a masked
> contour plot.Matplotlib can do it good.
>
> in my case,
> x is array for axis X and y for axis Y
> z is data for contour
> mask is a mask array with the same dimensions as z.
> ma.array(z,mask=mask)
> contour(x,y,z)
>
> In my case,I used kriging interpolation to interpolate an array of
> irregulation station data into a rectangular grid first and then plot
> contour with matplotlib. I wanna know if matplotlib have such
> interpolation functions or geostatistics functions. 
>
> Thanks again.
>
> shu
>
> 
Shu: It's not included in matplotlib, but see
http://www.scipy.org/Cookbook/Matplotlib/Gridding_irregularly_spaced_data
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

> Shu: I'd make a mask by finding the points on the grid that are outside 
> your polygon. Then use that mask to create a masked array from your 
> data (masking the points you don't want to plot). matplotlib's contourf 
> knows how to deal with masked arrays (at least when the masked region 
> isn't too complicated). The basemap toolkit can plot data on map 
> projections with coastlines and political boundaries (as in the PyNGL 
> example you forwarded).
> 
> -Jeff
Thanks Jeff.Following your advice I have successed to get a masked
contour plot.Matplotlib can do it good.
in my case,
x is array for axis X and y for axis Y
z is data for contour
mask is a mask array with the same dimensions as z.
ma.array(z,mask=mask)
contour(x,y,z)
In my case,I used kriging interpolation to interpolate an array of
irregulation station data into a rectangular grid first and then plot
contour with matplotlib. I wanna know if matplotlib have such
interpolation functions or geostatistics functions. 
Thanks again.
 shu

John Hunter wrote:
[...]
> Simson> To answer Eric's most recent posting:
> 
> Simson> 1. I think that scientific notation should not be the
> Simson> default, unless numbers exceed 1E+7. 
> 
> I agree with this -- scientific notation kicks in too soon IMO. I
> think an rc setting would be fine. I am not adverse to more rc
> settings personally. I haven't seen too many problems arising from
> having a lot of rc settings.
I have added an rc setting called axes.formatter.limits and set the 
defaults to -7, 7, so that now scientific notation starts at 1e+-7. This 
may be too large for some tastes--but at least now it is configurable. 
Maybe other users will comment on what they think the defaults should 
be. I don't have a strong opinion.
I also added a convenience method to the Axes class (called 
ticklabel_format())to make it easier to turn scientific notation on or 
off on either or both axes, with the idea that other formatting control 
might be added to the method later. I have not made the method a pylab 
function yet; I would rather wait until it settles down and people have 
had a chance to request a different name or turn thumbs down on the 
whole thing or whatever.
Suggestions for better names or other aspects of these API additions are 
welcome. I have found it difficult to come up with short and 
descriptive names, and don't feel I have done particularly well.
> 
> Simson> 2. It would be nice if there was an easy way to get commas
> Simson> into numbers. (This is forever a problem; I wish that the
> Simson> original C folks had thought to put commas into their
> Simson> original printf formatting. I have a nice python commas
> Simson> function if you want it, although you can probably create
> Simson> one that is more efficient.)
I wrote part of an "add_commas" function with the idea of letting its 
use be an option in the ScalarFormatter--I think this would be better 
than adding a whole separate Formatter. But it is not finished (lacks 
support for signs and exponential notation) and I need to do other 
things now. Simson, if you have not already plunged into John's 
suggestion below, I would be happy to see your comma function--please 
send it. But if you are inspired to come up with a comma-adding 
formatter or modification to ScalarFormatter, that's even better.
> 
> This would be a great custom formatter -- see
> http://matplotlib.sf.net/matplotlib.ticker.html for details on the
> Formatter. Please contribute one if you can.
[...]
Eric