matplotlib-users Mailing List for matplotlib (Page 13)

Hi list,=0A=0AMust be a dumb question: How do I draw a line going from poin=
t A to point B on a figure (not plot reference frame), with a particular co=
lor and style?=0A=0AI scan through the manual and nothing jumped out - clos=
est is Rectangle but that doesn't accept style parameter.=0A=0AThanks,=0A =
=0A--=0AJohn Henry=0A=0A

Yannick Copin wrote:
> Hi,
> 
> I take the opportunity of a recent thread about axes label to reiterate 
> a question I posted some time ago:
> 
> Is there a way (best would be a default parameters in matplotlibrc) to 
> automagically plot minor ticks?
I think that what you need to do is to explicitly set both the major and 
the minor locator to a MultipleLocator, but with different bases:
ax.xaxis.set_major_locator(MultipleLocator(base=1))
ax.xaxis.set_minor_locator(MultipleLocator(base=0.5))
This assumes you know enough about the range to know what suitable bases 
are. If this is not the case, then you could use an explicit call to 
MaxNLocator(nminor).bin_boundaries(xmin, xmax) to help you select the 
minor base, and multiply it by 2, or 4, or 5, or whatever you like to 
get the major base. This will work if xmax-xmin is not too far removed 
from xmax and xmin.
Eric
> 
> I *thought* I knew how to add them manually using e.g.
> ax.xaxis.set_minor_locator, but I dont know how to handle them 
> automatically. E.g. my simplest guest was to use LinearLocator:
> 
> x = randn(100)
> y = randn(100)
> plot(x,y,'bo')
> ax = gca()
> ax.xaxis.set_minor_locator(LinearLocator())
> 
> But these minor ticks wont (necessarily) be coherent with the automatic 
> major ticks:
> 
> L = ax.xaxis.get_major_locator()
> l = ax.xaxis.get_minor_locator()
> 
> print L()
> [-4. -3. -2. -1. 0. 1. 2. 3. 4.]
> 
> print l()
> [-4. -3.2 -2.4 -1.6 -0.8 0. 0.8 1.6 2.4 3.2 4. ]
> 
> (see, it will look like |.......:.|.....:...|...:.....|.:...)
> 
> How could I do to have some minor ticks automagically coherent with the 
> automated major ticks?
> 
> Cheers.

Marek Wojciechowski wrote:
> 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?
>
> 
Dear Marek,
The 3D plotting in matplotlib is not going to be fast (with the current 
approach). It is inherently doing the 3D->2D transform in software (and 
in Python, IIRC). Until a major re-write (of this part of the code, at 
least, if not the entire MPL transform system), your best bet for 
interactive 3D plotting is something else, such as tvtk's mlab package.
Cheers!
Andrew

Dear All
I'm happy and proud to announce that a repository for free chemometric 
software (in particular Python oriented) has started.
at www.chemometrics.it
Some time ago I've sent an email to the ICS asking if anybody knows 
the esistence of a python repository for chemometrics,
I had a positive feedback from the community and with the help of other 
chemometricians I've decided to gather free
software available for doing common chemometric tasks.
In the site you will also find a forum where to discuss
-> theoretical aspects of chemometrics
-> job opportunities and cooperation with other chemometricians
-> software request/news
I've tried to link to existing sites that already give a huge contribute 
to chemometrics (KVL,Chemometrics.se just to cite two of them)
but I will be very glad if you would like to contribute with your own links
I hope this initiave could help to spread chemometrics and the use of 
free routine/software for chemometrics but that
it also will become a place of discussion for anybody interested.
Obviously we need your help and enthusiasm.
If you would like to upload software links, routines etc, just register 
for free and do it, it's just so easy and you are very encouraged to do it.
The initiave is just at its beginning so feel free to report any 
technical problem
Any kind of feedback is appreciated
Since it's a no profit personal initiave (I bought the domain and the 
rent the hosting) finally let me say that any mirroring or hosting 
will be greatly appreciated.
I hope that this initiative will be useful ;)
Best Regards
Giorgio Luciano
-- 
-======================-
Dr Giorgio Luciano Ph.D.
Di.C.T.F.A. Dipartimento di Chimica e Tecnologie Farmaceutiche e Alimentari
Via Brigata Salerno (ponte) - 16147 Genova (GE) - Italy
email lu...@di...
-======================-

Hi --
I'm just starting with matplotlib and scipy on a Mac. I was able to get some 
plots to work under X (using the gtk+ renderer), but I wanted to avoid that and 
use CocoaAgg (that's the best option for mac, right?)
When using the default renderer, it looks like the window (under X11) was in a 
separate thread and new plots showed up until I cleared.
However, when I use CocoaAgg (and ipython), plot brings up a blank 
metal-looking window, and then the plot I wanted, but ipython blocks until I 
close it.
Is this expected?
I downloaded everything from darwinports, and dropped in the .nibs which seemed 
to be in wrong -- they're XML and it doesn't complain.
What I do:
------------
$ ipython -pylab
Python 2.4.3 (#1, Feb 23 2007, 06:25:26)
Type "copyright", "credits" or "license" for more information.
IPython 0.7.2 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
 Welcome to pylab, a matplotlib-based Python environment.
 For more information, type 'help(pylab)'.
In [1]: x = arange(-5,5,0.01)
In [2]: y = sin(x)
In [3]: plot(x,y)
<after I close the window>
Out[3]: [<matplotlib.lines.Line2D instance at 0x10c5620>]
$ cat ~/.matplotlib/matplotlibrc
backend: CocoaAgg
Any help appreciated.
Ranjan

Christopher Barker wrote:
[...]
> 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.
Sometimes plot creates a figure, sometimes it creates an axes, sometimes 
neither, but it always creates one or more Line2D objects, so that is 
what it returns--a list of lines. As far as I can see, it *has* to 
return this, or something containing this, so that one can work later 
with these most fundamental objects that it makes. An alternative would 
be some sort of LineSet object like the ContourSet object returned by 
contour, with lots of extra information, but I don't know that there 
would be any advantage.
Anyway, the point is that your alternatives for plot to return would not 
work well in practice, but what it does return now works fine, both for 
plot() and for ax.plot().
Eric

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