matplotlib-users Mailing List for matplotlib

John Hunter wrote:
> On 2/27/07, Christopher Barker <Chr...@no...> wrote:
>> There is nothing inherent in OO
>> design that makes it necessary to write a bunch more code.
> 
> I don't agree with this at all. Inherent in OO design is object
> creation, attribute setting and method calling. pylab automates some
> of these steps, which in any OO design can be a little repetitive, via
> figure management and current axes handling.
OK, maybe there is inherently a little more code in an OO framework, but 
the case at hand was perhaps 4 lines of code wrapped up in a pylab 
function -- that could just as easily be 4 lines of code in a matplotlib 
class method.
Also, I think there is a distinction between talking about "functional 
vs. OO" and the automated figure and axis management.
For example, the standard way to manipulate objects with a functional 
interface is something like:
Afunction(AnObject, TheParameters)
in OO, it's:
AnObject.TheMethod(TheParamerters)
Exactly the same amount of typing, but I think the later is cleaner.
As far as pylab goes, the introduction of state: current axis and 
current figure, lets you avoid specifying the object you want to act on, 
so yes, you do save some typing there.
However, I do think that it would be possible to make a nice OO 
interface for interactive use -- perhaps that would mean keeping a 
current figure and axis, and I think with auto generation, we could get 
close:
> >>> plot([1,2,3])
> 
> OK, that's nice and easy, but we just reinvented pylab 'plot', which
> really does nothing except manage the current Axes and Figure and
> forward the rest on to Axes.plot.
It is nice to have a really simple plot command. What would it do if we 
were trying to be fully OO? My key question is whether it would return 
and axis, a figure or both:
Fig, ax = plot([1,2,3])
then:
ax.xlabel("whatever")
isn't bad for me.
> pylab does nothing except manage
> the boiler plate that comes from using an OO framework -- basically it
> automates object instantiation and method calling by inferring which
> objects you want to create and which objects you want to forward the
> method calls to. And in my opinion, it does so pretty well.
Yes, it does, and it does have key advantages for interactive use. I 
think where my opinions come from is two key points:
1) I never really do all that much interactively -- I used Matlab for 
years, and now Python for years. In both cases, I write maybe a few 
lines to test things interactively, but if I'm writing more than 3 lines 
or so, I write a small script -- one that I'm likely to want to paste 
into a larger code base at some point.
2) the pylab interface really does get in the way and make me less 
productive for larger bodies of code.
So I want ONE interface, and I want it optimized for large code bases, 
but still simple enough to not be painful for small scripts and 
interactive use.
> In my experience, save for a
> little boilerplate for figure and axes creation, and the occasional
> verbosity of some getters and setters, the current OO API is pretty
> easy to use.
I agree. I think we are close. This thread started because it was 
suggested that some code put into pylab be moved into the axis class (I 
think it was the axis class) so that OO users could have easy access to 
that functionality too.
> The one thing that is clearly more verbose than it needs to be to me
> is the use of the setters and getters.
Agreed.
> Probably the reason there is limited impetus to do so is that it is
> even easier (and less typing) to use keyword args in the current API
> (and in pylab since pylab just forwards them to the API)
> 
> ax.text(1, 2, 'hi mom', color='black')
> 
> and in fact using multiple kwargs is a good bit less typing than using
> multiple properties.
True, but what about:
ax.xlabel="a label"
and the like. I like properties -- they feel Pythonic to me.
> I suggest you start a wiki page on the matplotlib Cookbook
> site listing the problems you see with the API and specific things you
> would like to see changed, so the discussion can be more productive.
Good idea. I've always intended to contribute more. I've mostly been 
waiting for a project where I'm really using MPL enough to know what I 
need. I've got one coming up, we'll see.
Meanwhile, I use a far too much time kibitzing on mailing lists...
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 3/2/07, John Hunter <jd...@gm...> wrote:
>
> John said:
> ...here is the minimal interface that
> appears to work
>
>
> class C(object):
> def __init__(self):
> self._data = (1,2,3,4,5)
>
> def __getitem__(self, i):
> return self._data[i]
>
> def __len__(self):
> return len(self._data)
>
>
> import numpy
> c = C()
> print numpy.asarray(c)
>
To all,
Thanks for the help. I had the other member functions implemented and I
simply needed to add the __getitem__ member function.
BTW: I am actually using Boost.Python to expose my C++ library to Python. I
was able to add the __getitem__ member function to my class and
voila...things worked nicely (I already had the __len__ member function).

On Thu, 1 Mar 2007, Eric Firing wrote:
> I agree, and this is a problem with spy also. If I remember, I will fix it.
> It is only a minor annoyance, so it is low priority, though.
>
> There is a difference in the way the axes are labeled between spy and
> matshow, and I would like to change matshow to agree with spy, unless there
> is an outcry to the contrary. Specifically, I think the integer axis ticks
> should land in the middle of a given row or column, not on the edge. To see
> what I mean, compare
>
> xx = zeros((3,3))
> xx[1,1] = 1
> spy(xx, marker='s')
> to
> matshow(xx)
>
> Maybe this is exactly what you mean by your next statement?
> 
> > Further, I would think a setting like align='center' in pylab.bar() would
> > be appropriate. Any simple way of doing this without manually setting 
> > the
> > ticks and labels (ironically using forced *.5 ticks)?
Yes, that is exactly what I meant. For now I am doing the following when
using matshow():
xa, xl = pylab.xticks()
pylab.xticks(xa + 0.5, [str(int(a)) for a in xa])
ya, yl = pylab.xticks()
pylab.yticks(ya + 0.5, [str(int(a)) for a in ya])
which shifts the ticks to the centre from the left edge. In cases where
the last tick falls at far edge of the plot, I modify the above with
xa[:-1]+0.5 and ya[:-1]+0.5 as needed for each axis.
The above code does raise another question. Originally, I tried
xa, xl = pylab.xticks()
pylab.xticks(xa+0.5, xl)
but I received a type error for the xl argument:
 File "/usr/lib64/python2.4/site-packages/matplotlib/text.py", line 671, in 
set_text
 raise TypeError("This doesn't look like a string: '%s'"%s)
TypeError: This doesn't look like a string: '<matplotlib.text.TextWithDash 
instance at 0x2aaaaac9afc8>'
This error is received when the plot is rendered after a call to pylab.show(). 
Why doesn't the object returned from pylab.xticks() work when you send it back 
to itself as an argument? Seems weird, especially since there is no problem 
with pylab.xticks(xa, xl) accepting it.
Cheers,
Suresh

Hi!
I created scatter3d plot with ca. 2000 points and i'm experiencing very,
very slow behavior in the interactive window. Rotate/move/zoom options are
not usable actually. Does anyone else experience this problem?
-- 
Marek Wojciechowski

On 3/2/07, Alan Isaac <ai...@am...> wrote:
> John asked:
> > What is the minimum interface for an object to be
> > converted to a numpy sequence via as array?
>
> The class must inherit from object.
> That will probably do it.
> If all else fails, try fromiter.
>
I know it works with fromiter, but I am trying to find a way mpl users
can create objects that will work directly in mpl, which uses asarray.
 Thanks for the object suggestion; here is the minimal interface that
appears to work
class C(object):
 def __init__(self):
 self._data = (1,2,3,4,5)
 def __getitem__(self, i):
 return self._data[i]
 def __len__(self):
 return len(self._data)
import numpy
c = C()
print numpy.asarray(c)

On Friday 02 March 2007 14:12:24 John Hunter wrote:
> I still am not able to make my mock-up custom python class work as I
> would like with asarray (though it works with "list"). What am I
> missing? The way I read it this appears to be in support of extension
> code that wants to expose the array interface, but I have a python
> object that acts like a sequence (am I missing some important method)
> that wants to work properly with numpy.asarray
John,
Why wouldn't you use the numpy.core.ma implementation of masked arrays as a 
source of inspiration ? After all, what (I think) you're doing is pretty 
close to how masked arrays were initially implemented, as a class on its own, 
not derived from ndarray.
Basically, that would amount to define a __array__() method that would return 
the numpy equivalent of your object.
Or you can try to use Pyrex for your new class. That works well if you don't 
try to subclass ndarray.

John asked:
 > What is the minimum interface for an object to be
 > converted to a numpy sequence via as array?
The class must inherit from object.
That will probably do it.
If all else fails, try fromiter.
Alan Isaac

On 3/2/07, Christopher Barker <Chr...@no...> wrote:
> This sounds like EXACTLY the type of object that the array interface is
> supposed to support. So what you need to do is give your object an array
> interface:
>
> http://numpy.scipy.org/array_interface.shtml
I still am not able to make my mock-up custom python class work as I
would like with asarray (though it works with "list"). What am I
missing? The way I read it this appears to be in support of extension
code that wants to expose the array interface, but I have a python
object that acts like a sequence (am I missing some important method)
that wants to work properly with numpy.asarray
class C:
 def __init__(self):
 self._data = (1,2,3,4,5)
 def __iter__(self):
 for i in self._data:
 yield i
 return
 def __getitem__(self, i):
 return self._data[i]
 def __getslice__(self, i, j):
 return self._data[i:j]
 def __len__(self):
 return len(self._data)
 def __array_interface__(self):
 return dict(
 shape=(len(self._data),),
 typestr='f',
 version=3)
import numpy
c = C()
print numpy.asarray(c)
#for i in c:
# print i

kc1...@ya... writes:
> The method proposed by Jouni appears to work too:
> gca().yaxis.set_major_locator(LinearLocator())
> but it created too many labels.
It's just the default behavior. Please see
http://matplotlib.sourceforge.net/matplotlib.ticker.html#LinearLocator
or simply query the documentation of LinearLocator in ipython:
| Constructor information:
| Definition: LinearLocator(self, numticks=None, presets=None)
| Docstring:
| Use presets to set locs based on lom. A dict mapping vmin, vmax->locs
The docstring is kind of cryptic (what's a lom?) but the numticks
keyword argument hints that you can set the number of ticks, e.g.
 gca().yaxis.set_major_locator(LinearLocator(numticks=4))
But, as John said, if you already know where you want the ticks, you
can just set them directly.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Thanks to the reply, John (Hunter).=0A=0AThat's it. The method proposed b=
y Jouni appears to work too:=0A=0Agca().yaxis.set_major_locator(LinearLocat=
or())=0A=0Abut it created too many labels.=0A=0AThe set_ytinks call is the =
key. The set_ylim doesn't seem to be necessary. Now I have to study and s=
ee how I can implement it as a custom locators.=0A=0AThanks,=0A=0ABTW: John=
, many thinks to an excellant package.=0A=0A> > How do I force the first la=
bel to appear at the origin for =0A> all plots?=0A> =0A> How about=0A> =0A>=
 ax.set_ylim(-1.1,1.1)=0A> ax.set_yticks([-1.1, 0, 1.1])=0A> =0A> etc..=
.=0A> =0A> You can use custom locators as above to automate this, but if =
=0A> you know the ticks you want, just set them.=0A> =0A =0A--=0AJohn Henry=
=0A=0A

John Hunter wrote:
> But numpy.asarray, which is what mpl uses to convert inputs to
> arrays,
The whole idea of asarray, is that it should be able to convert properly
defined objects without even copying the data.
> my own custom class which contains data members, methods and an array
> of data (underlying C array)
This sounds like EXACTLY the type of object that the array interface is 
supposed to support. So what you need to do is give your object an array 
interface:
http://numpy.scipy.org/array_interface.shtml
once you've done that, asarray() should "just work" and therefore all of 
MPL should just work.
However, I would post a question about this to the numpy list -- there 
is an effort at the moment to have an n-d buffer protocol defined for 
Python 3.0.
http://projects.scipy.org/mailman/listinfo/numpy-discussion
I'm not sure at this point whether you'd be best off implementing the 
above interface or the new buffer protocol that's being discussed:
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/pep_buffer.txt
The numpy folks will be able to help.
By the way, this is a good example why the above PEP is a good idea!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 3/2/07, kc1...@ya...
<kc1...@ya...> wrote:
> Somebody at the usenet suggested that I play with the ticker formatter and locator. While that helped the multi-color sample I cited, it didn't help in my plots. The formatter only controls how the y-axis labels are formatted, whereas AFAIK the locator only affects the values of the ymajor and yminor.
>
> So, back to my original question:
>
> How do I force the first label to appear at the origin for all plots?
How about
 ax.set_ylim(-1.1,1.1)
 ax.set_yticks([-1.1, 0, 1.1])
etc...
You can use custom locators as above to automate this, but if you know
the ticks you want, just set them.

kc1...@ya... writes:
> Somebody at the usenet suggested that I play with the ticker
> formatter and locator. While that helped the multi-color sample I
> cited, it didn't help in my plots. The formatter only controls how
> the y-axis labels are formatted, whereas AFAIK the locator only
> affects the values of the ymajor and yminor.
This works for me:
 figure()
 gca().yaxis.set_major_locator(LinearLocator())
 x=arange(0, 7, 0.01)
 plot(sin(x))
 gca().set_ylim((-1.1,1.1))
 show()
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 3/2/07, Simon Wood <sgw...@gm...> wrote:
python > Out of the box matplotlib works great with Numeric and
numarray data types.
> However, I have my own custom class which contains data members, methods and
> an array of data (underlying C array). Is there a way to expose the C array
> data to the plot() routines? For example I would like to be able to use
> plot(X) where X is an instantiated object of type MyClass.
My initial response was if your object supports iteration, it will
work with matplotlib But I just tested this and found it to be false.
 class C:
 def __init__(self):
 self._data = (1,2,3,4,5)
 def __iter__(self):
 for i in self._data:
 yield i
 return
 def __len__(self):
 return len(self._data)
c = C()
for i in c:
 print i
But numpy.asarray, which is what mpl uses to convert inputs to arrays,
 fails with this object.
In [16]: c = C()
In [17]: numpy.asarray(c)
Out[17]: array(<__main__.C instance at 0x8d04f6c>, dtype=object)
because it treats it as an object array (but list(c) works as
expected). What is the minimum interface for an object to be
converted to a numpy sequence via as array?
Setting up your object to work with the numpy asarray conversion
facility is probably your best bet pending answers to the question
above. But, if your object doesn't expose the proper interface, and
for some reason you cannot modify or wrap your objects to expose it,
we have a branch of svn to handle plotting of types with unit
information, but this branch will also support plotting of arbitrary
user types. One can register their type with a set of converter
functions, and then do
 >>> plot(myobj)
myobj does not need to expose any particular interface, as long as you
have registered a converter with matplotlib -- the converter maps
object type to classes that know how to convert your object to. This
enable you to use custom objects (usually coming from 3rd part
extension code that you do not want to wrap or modify) with
matplotlib. Some basic examples are in examples/units and the
documentation is in lib/matplotlib/units.py
Michael, can you point Simon to a minimal example in the unit's branch
that would show him how to use the new units registry for a custom
object? Just to be clear, he doesn't need the unit handling, so would
just need the default locator and formatter, but he would need the
to_array conversion and object type registry. I think this will be an
important use case for this code that was not part of the original
plan. I think the basic idea is that an important use case will be
one where the user doesn't care about units or tagged values or
locators and formatters, and we should provide a base converter than
encapsulates all this for them, and then all the need to do is derive
from this class and register with the figure. It also suggests we may
want to rename register_default_unit_conversion to
register_default_conversion.
The svn branch lives in
> svn checkout https://svn.sourceforge.net/svnroot/matplotlib/branches/unit_support/matplotlib mplunits
JDH

Somebody at the usenet suggested that I play with the ticker formatter and =
locator. While that helped the multi-color sample I cited, it didn't help=
 in my plots. The formatter only controls how the y-axis labels are forma=
tted, whereas AFAIK the locator only affects the values of the ymajor and y=
minor. =0A=0ASo, back to my original question:=0A=0AHow do I force the fir=
st label to appear at the origin for all plots?=0A=0AThanks,=0A=0A> =0A> =
=0A> I found an example on the web that illustrates the question I =0A> pos=
ted earlier about axes. See:=0A> =0A>http://www.scipy.org/Cookbook/Matplot=
lib/MulticoloredLine=0A=0A>Notice that the y-axis goes from (-1.1, 1.1) but=
 the first label is at -1.0. I really don't like that because when I read=
 values off the graph, I have to keep reminding myself that the >origin is =
at -1.1. This may seem trivial but if you have to think, walk, chew gums =
at the same time you're reading the graph, it gets annoying - particularly =
if you have to read lots >of these graphs.=0A=0A>Is there a way to force th=
e label to start at -1.1 instead of -1.0?=0A=0A>Thanks,=0A =0A--=0AJohn Hen=
ry=0A=0A

Jouni K. Seppänen <jk...@ik...> writes:
> Anand Patil <an...@so...> writes:
>> - When I inserted some of my old pdf plots into a latex presentation, to 
>> my surprise their foreground color had changed from black to the color 
>> of the text in the presentation. Is there a way to signal to Matplotlib 
>> that I would like this to happen? Can I make this behavior default?
>
> Certainly there is no such intended feature in matplotlib. I think I
> could support it for monochromatic plots quite easily, 
I added a new rc parameter pdf.inheritcolor to enable this. You will
probably want to disable the figure and axes frames if you use it, as
both the fill and stroke colors will be inherited from the surrounding
environment, and the frames are filled by default.
I got some error messages from svn, but it looks like the change is
now there. (To check, see if CHANGELOG has an entry for 2007年03月02日
describing this change.)
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Fri, Mar 02, 2007 at 08:46:24AM -0600, Glen W. Mabey wrote:
> P.S. You may also need to implement functions like __len__; if these
> concepts are well-defined for your class, then it should be a very
> straightforward process.
But the problem is (if your experience is similar to mine) that then
you'll want to implement __iter__ too, and you'll start liking this
combination of python, numpy, and matplotlib *way* too much.
Glen

On Fri, Mar 02, 2007 at 08:44:02AM -0600, Glen W. Mabey wrote:
> One approach that I've used recently is to simply provide functionality
> for the [] operator (done by implementing the __getslice__ member
> function) that accesses the data according to standard slicing rules.
> Then, you can use plot() directly.
P.S. You may also need to implement functions like __len__; if these
concepts are well-defined for your class, then it should be a very
straightforward process.
Glen

On Fri, Mar 02, 2007 at 09:41:03AM -0500, Simon Wood wrote:
> Out of the box matplotlib works great with Numeric and numarray data types.
> However, I have my own custom class which contains data members, methods and
> an array of data (underlying C array). Is there a way to expose the C array
> data to the plot() routines? For example I would like to be able to use
> plot(X) where X is an instantiated object of type MyClass.
One approach that I've used recently is to simply provide functionality
for the [] operator (done by implementing the __getslice__ member
function) that accesses the data according to standard slicing rules.
Then, you can use plot() directly.
Glen

Anand Patil <an...@so...> writes:
> - How can I make my figures and axes transparent by default?
Here's one idea:
------------------------------------------------------------------------
In [1]:fig=figure(frameon=False)
In [2]:ax = fig.add_subplot(111, frameon=False)
In [3]:ax.plot([3,1,4,1,5,9,2])
Out[3]:[<matplotlib.lines.Line2D instance at 0x2c98b70>]
In [4]:show()
In [5]:savefig('foo.pdf')
------------------------------------------------------------------------
And here's another:
------------------------------------------------------------------------
In [20]:fig=figure()
In [21]:fig.figurePatch.set_alpha(0.1)
In [22]:ax=fig.add_subplot(111) 
In [23]:ax.axesPatch.set_alpha(0.1)
In [24]:ax.plot([3,1,4,1,5,9,2])
Out[24]:[<matplotlib.lines.Line2D instance at 0x16f7e490>]
In [25]:show()
In [26]:savefig('foo.pdf')
------------------------------------------------------------------------
Does either of these do what you are looking for?
> - When I inserted some of my old pdf plots into a latex presentation, to 
> my surprise their foreground color had changed from black to the color 
> of the text in the presentation. Is there a way to signal to Matplotlib 
> that I would like this to happen? Can I make this behavior default?
Were the old pdf plots produced with the pdf backend, or with the eps
backend and then converted to pdf with some external utility?
I'm guessing that what happened was that the pdf file didn't specify
any color, and when it was included, it inherited the graphics state
from the including pdf file. I'm not quite sure if that's supposed to
happen when including files, although I can of course see how it could
be considered a useful feature.
Certainly there is no such intended feature in matplotlib. I think I
could support it for monochromatic plots quite easily, but it would be
much trickier if you want part of the plot in the inherited color and
another part in a specified color.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Out of the box matplotlib works great with Numeric and numarray data types.
However, I have my own custom class which contains data members, methods and
an array of data (underlying C array). Is there a way to expose the C array
data to the plot() routines? For example I would like to be able to use
plot(X) where X is an instantiated object of type MyClass.
Thanks,
-Simon

kc1...@ya... writes:
> a) 2.3 doesn't have the sorted function - it uses a .sort()
> function. So, I had to change line 487 from:
I think this was taken care of by Nicolas Grilly's recent patch.
> b) No update() function (line 396)
> for (name, value) in self.markers.items():
> xobjects[name]=value[0]
Applied in svn, thanks!
> After that, I got my pdf file. However, if I print the PDF directly,
> works fine but when I create an object link to the PDF and print
> from inside Word, the printout is degraded (kind of fuzzy with
> texts).
That sounds to me like a bug in Word (as does the invalidrestore
thing).
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I installed the numpy-1.0.1 successfully, but failed to install matplotlib
0.90. My linux env is DreamHost Debian Linux. There are some things I can't
control.
Anyone successfully doing so on DH hosted machine? Thanks!
[catalina]$ ../python2.5/bin/python setup.py install
GTK requires pygtk
GTKAgg requires pygtk
TKAgg requires TkInter
running install
running build
running build_py
running build_ext
building 'matplotlib.backends._ns_backend_agg' extension
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC
compile options:
'-I/home/.makayla/codev/python2.5/lib/python2.5/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I. -Isrc -Iswig -Iagg23/include -I.
-I/usr/local/include -I/usr/include -I.
-I/home/.makayla/codev/python2.5/lib/python2.5/site-packages/numpy/core/include/freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-I/home/.makayla/codev/python2.5/include/python2.5 -c'
extra options: '-DSCIPY=1'
gcc: src/_image.cpp
In file included from
/home/.makayla/codev/python2.5/include/python2.5/Python.h:8,
 from src/_image.cpp:7:
/home/.makayla/codev/python2.5/include/python2.5/pyconfig.h:932:1: warning:
"_POSIX_C_SOURCE" redefined
In file included from /usr/include/c++/3.3/i486-linux/bits/os_defines.h:39,
 from /usr/include/c++/3.3/i486-linux/bits/c++config.h:35,
 from /usr/include/c++/3.3/iostream:44,
 from src/_image.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the previous
definition
gcc: src/ft2font.cpp
In file included from
/home/.makayla/codev/python2.5/include/python2.5/Python.h:8,
 from CXX/Objects.hxx:9,
 from CXX/Extensions.hxx:19,
 from src/ft2font.h:18,
 from src/ft2font.cpp:2:
/home/.makayla/codev/python2.5/include/python2.5/pyconfig.h:932:1: warning:
"_POSIX_C_SOURCE" redefined
In file included from /usr/include/c++/3.3/i486-linux/bits/os_defines.h:39,
 from /usr/include/c++/3.3/i486-linux/bits/c++config.h:35,
 from /usr/include/c++/3.3/iosfwd:45,
 from /usr/include/c++/3.3/ios:44,
 from /usr/include/c++/3.3/istream:44,
 from /usr/include/c++/3.3/sstream:44,
 from src/ft2font.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the previous
definition
gcc: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>.
In file included from
/home/.makayla/codev/python2.5/include/python2.5/Python.h:8,
 from CXX/Objects.hxx:9,
 from CXX/Extensions.hxx:19,
 from src/ft2font.h:18,
 from src/ft2font.cpp:2:
/home/.makayla/codev/python2.5/include/python2.5/pyconfig.h:932:1: warning:
"_POSIX_C_SOURCE" redefined
In file included from /usr/include/c++/3.3/i486-linux/bits/os_defines.h:39,
 from /usr/include/c++/3.3/i486-linux/bits/c++config.h:35,
 from /usr/include/c++/3.3/iosfwd:45,
 from /usr/include/c++/3.3/ios:44,
 from /usr/include/c++/3.3/istream:44,
 from /usr/include/c++/3.3/sstream:44,
 from src/ft2font.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the previous
definition
gcc: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>.
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC
-I/home/.makayla/codev/python2.5/lib/python2.5/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I. -Isrc -Iswig -Iagg23/include -I.
-I/usr/local/include -I/usr/include -I.
-I/home/.makayla/codev/python2.5/lib/python2.5/site-packages/numpy/core/include/freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-I/home/.makayla/codev/python2.5/include/python2.5 -c src/ft2font.cpp -o
build/temp.linux-i686-2.5/src/ft2font.o -DSCIPY=1" failed with exit status 1
[catalina]$

Suresh Pillai wrote:
> Great, matshow() works for my requirements.
> 
> Although, I must comment that its placement of tickbars seems 
> inappropriate for a matrix visualisation. For example, for the following 
> simple example:
> 
> import pylab
> 
> matrix = pylab.array([[1,2,3],[4,5,6],[1,1,4]])
> pylab.matshow(matrix, cmap=pylab.cm.gray)
> pylab.show()
> 
> tick marks and labels are produced for [0.5,1.5,2.5] in addition to the 
> appropriate integral ones. It's obviously not an issue for larger 
> matrices.
I agree, and this is a problem with spy also. If I remember, I will fix 
it. It is only a minor annoyance, so it is low priority, though.
There is a difference in the way the axes are labeled between spy and 
matshow, and I would like to change matshow to agree with spy, unless 
there is an outcry to the contrary. Specifically, I think the integer 
axis ticks should land in the middle of a given row or column, not on 
the edge. To see what I mean, compare
xx = zeros((3,3))
xx[1,1] = 1
spy(xx, marker='s')
to
matshow(xx)
Maybe this is exactly what you mean by your next statement?
> 
> Further, I would think a setting like align='center' in pylab.bar() would 
> be appropriate. Any simple way of doing this without manually setting the 
> ticks and labels (ironically using forced *.5 ticks)?
Eric