matplotlib-devel Mailing List for matplotlib (Page 3)

[Moving to the devel list.]
Here's a patch for font_manager.py to close opened files. Could
somebody review the patch? As I mentioned earlier, I don't understand
why cPickle/pickle is not imported at the top level, so I'm hesitant
to check this in without review.

Hi everybody,
I made some progress with my data plotting program.
now I have stumbled in a new problem: I want to be able to move the
data cursor by pressing a key, say '.' to move right, ',' to move
left. I thought I was smart enough and added a method to the
DataCursor class:
 def moveto(self, event, ind):
 """
 """
 event.xdata = self.t[ind]
 event.ydata = self.y[ind]
 self.xstr = '%1.3f'%event.xdata
 self.ystr = '%1.3f'%event.ydata
 print event.xdata, event.ydata, event
 print self.xstr, self.ystr, event
 Cursor.onmove(self, event)
the event is caught in the main loop and sent of DataCursor.moveto
however, the cursor does not move at the end of this method as I had
hoped for. I suspect the reason is the reason is that this method is
getting a keyEvent, not a mouseEvent and then onmove doesn't like it.
the original Cursor class looks for mouseEvents, not for keyEvents.
What should I do? Is there a way to translate a keyEvent into a mouse
event, so I can fool the Cursor class? another more elegant solution?
Also, after I hit '.' or ',' the cursor goes off. I can turn it back
on hitting 1 and 2.
I attach a sample test code that uses essentially John's original code
plus this modification.
cheers
Antonio
Antonio Kanaan
Departamento de Fisica - Universidade Federal de Santa Catarina
CP 476 -- CEP 88040-900 -- Florianopolis -- SC -- Brasil
http://www.astro.ufsc.br/~kanaan e-mail: ka...@as...
Phone: 55,48,33319069 FAX : 55,48,33319946
moveto is called from the main loop when I hit either '.' or ','
On 2/26/07, John Hunter <jd...@gm...> wrote:
> On 2/26/07, Antonio Kanaan <ank...@gm...> wrote:
> > Hi folks,
> >
> > I am planning to re-write a data viewer program I wrote ages ago using C + Xlib.
> >
> > This program allows me to plot on the same window several graphs (time
> > versus brightness - I work on variable stars). They all share the
> > same independent variable (time passes the same for everybody).
> >
> > I can scroll and zoom the graphs both in X and Y. When I scroll/zoom
> > in X all plots suffer the same action. Y scrolling/zooming may be
> > done for each plot.
> >
> > Now the question: I need a data cursor, by that I mean some marker
> > that sits on top of a point and which may be moved forward/backward by
> > pressing a key. Matplotlib has a mouse cursor that gives me the
> > cursor coordinates, but it doesn't
>
> This isn't too bad actually -- you can subclass the existing Cursor
> class to override the xdata and ydata atrributes to insure that the
> cursor sits only on your data points. The example below uses the
> cursor class to overrride the toolbar formatting, and shows you how to
> toggle the visibility of multiple cursors in multiple axes with shared
> x axes. I'll also attach it in case the mail system mangles the
> newlines. Take a look at the MultiCursor in
> the widgets module, you might be able to do a similar trick there to
> have common x cursoring across multiple axes.
>
> from pylab import figure, show, nx
> from matplotlib.widgets import Cursor
>
> class DataCursor(Cursor):
> def __init__(self, t, y, ax, useblit=True, **lineprops):
> Cursor.__init__(self, ax, useblit=True, **lineprops)
> self.y = y
> self.t = t
> self.xstr = ''
> self.ystr = ''
>
> def onmove(self, event):
> """
> we override event.xdata to force it to snap-to nearest data
> item here we assume t is sorted and I'll use searchsorted
> since it is a little faster, but you can plug in your nearest
> neighbor routine, eg to grab the closest x,y point to the
> cursor
> """
> xdata = event.xdata
> ind = nx.searchsorted(self.t, xdata)
> ind = min(len(self.t)-1, ind)
> event.xdata = self.t[ind]
> event.ydata = self.y[ind]
> self.xstr = '%1.3f'%event.xdata
> self.ystr = '%1.3f'%event.ydata
> Cursor.onmove(self, event)
>
> def fmtx(self, x):
> return self.xstr
>
> def fmty(self, y):
> return self.ystr
>
> fig = figure()
> ax1 = fig.add_subplot(211)
> ax2 = fig.add_subplot(212, sharex=ax1) # connect x pan/zoom events
>
> t = nx.cumsum(nx.rand(20))
> s1 = nx.mlab.rand(len(t))
> s2 = nx.mlab.rand(len(t))
>
> ax1.plot(t, s1, 'go')
> ax2.plot(t, s2, 'bs')
> ax1.set_title("Press 1 for upper cursor and 2 for lower cursor")
> cursor1 = DataCursor(t, s1, ax1, useblit=True, color='red', linewidth=2 )
>
> # we'll let the cursor do the toolbarformatting too.
> ax1.fmt_xdata = cursor1.fmtx
> ax1.fmt_ydata = cursor1.fmty
>
> cursor2 = DataCursor(t, s2, ax2, useblit=True, color='red', linewidth=2 )
> ax2.fmt_xdata = cursor2.fmtx
> ax2.fmt_ydata = cursor2.fmty
>
>
> # now we'll control the visibility of the cursor; turn off cursor2 by default
> cursor2.visible = False
>
> def keyevent(event):
> cursor1.visible = event.key=='1'
> cursor2.visible = event.key=='2'
> fig.canvas.draw()
>
> fig.canvas.mpl_connect('key_press_event', keyevent)
> show()
>
>
> >
> > - sit on top of my points and therefore doesn't give me the exact
> > value of that point
> > - allow me to move from one point to the next
> > - allow me to change which graph I want the cursor sitting on
> >
> > I thought of drawing my own cursor, deleting it and moving to the next
> > point . It seems this would take forever as (far as I understand)
> > matplotlib will redo the entire plot each time I do this.
> >
> > How hard is it for the developers to include a built in data cursor in
> > a similar fashion to the mouse cursor now available. I am affraid
> > this isn't too easy, I don't know any plotting program that has one
> > like what I need.
> >
> > thanks for your attention,
> >
> > Antonio Kanaan
> >
> > -------------------------------------------------------------------------
> > 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-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>

My apologies,
line 195 of my previously-attached python file containing the boxplot
method should have read
 if fill and not no_box:
i.e. using the parameter 'fill' and not 'dofill'. Sorry for the typo!

Dear matplotlib developers,
I am attaching an updated boxplot method for axes.py that I would like
to suggest as a replacement for the present one in 0.90. My code does
not change any of the existing functionality, and simply adds a few
options to the existing code:
* I wanted to be able to draw boxplots entirely in black.
* When plotting several boxes on the same axes, where some boxes are
very small in comparison to others, the box outline and notch can
totally mask the median line information. So I added an option to draw
*no* box if the box is sufficiently small so that the median line is
clear. The inner whisker limits provide the only information about q1
and q3 in this case.
* I personally don't find the adaptive notch size very attractive for
publication-quality plots. I added a feature to keep the notch size
fixed (notch==2). This means that very small boxes will foul up, so if
the fixed notch size is smaller than the box height then the "no box"
option is automatically forced on. Fixed notch size is set using the
'notchsize' parameter.
* I wanted to include an additional (and optional) line in the box for
the mean average of the data (but not associated with an additional
notch).
* I wanted to make the boxes white-fillable in case they are placed
over background lines.
* I wanted to set my own axes limits externally, and prevent ticks on
the plot so that I can label the graphs myself and add additional
info.
The attached PNG graphic exemplifies these suggestions with the new
code for a plot that is appearing in an IEEE journal article (please
ignore the black triangle that has nothing to do with the
boxplotting). All the new features involve optional parameters to the
method signature, defaulting in their absence to the existing
functionality.
The code for the method includes an updated docstring that reflects
how these features are used. Note that I've also made a few minor
edits to the existing parts of the docstring text for clarity: in
particular, regarding the return value, as the existing statement
apparently was not updated when the method was changed to return a
dictionary.
Please feel to discuss these ideas with me.
Regards,
Rob

"John Hunter" <jd...@gm...> writes:
> The call signature in the docstring should certainly be changed to
> match the new signature. 
Ok. I synced the docstrings of bar and barh.
> Also, take a look at the kwdocd stuff we have to see if you can make
> that work for the keyword args.
It was already being used for Rectangle properties in the bar
docstring, so I made the barh docstring use it as well. We could
separate some of the shared documentation of bar and barh into a
constant substituted into both docstrings, I'm not sure if it would be
a net win.
Another bug related to bar and barh is #1200213:
 http://sourceforge.net/tracker/index.php?func=detail&aid=1200213&group_id=80706&atid=560720
 http://thread.gmane.org/gmane.comp.python.matplotlib.devel/648
There are really three problems listed: that bar and barh have
different defaults for what is now the align argument; that the first
two arguments to barh were in illogical order; and that bar has the
yerr argument before xerr.
According to the discussion about the first problem, barh used to
interpret the y coordinates as the centers of the bars, not the edges,
which is not true today, as both bar and barh default to align='edge'.
It seems that this was eventually resolved in a direction opposite to
that suggested in the discussion at that time.
The second problem seems to have been fixed, and I'm not convinced
that the third one is really a problem. I suppose the bug could be
closed?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Saturday 03 March 2007 12:43:53 pm you wrote:
> On 2/23/07, Andrew Straw <str...@as...> wrote:
> > 2) make our own distutils monkeypatch a la setuptools. Looking at
> > setuptools/dist.py, this doesn't look trivial -- certainly beyond my
> > free bandwidth capacity.
>
> This is fine by me -- I actually was forced to think about this this
> morning as I tried to upgrade my powerbook to the latest svn. =A0I'm
> still on python2.3, and when I tried to install I hit the setuptools
> import. =A0I figured I would be a good crash test dummy to see how easy
> it was to install setuptools, so I poked around and found the ez_setup
> and am off to the races. =A0I added a friendly exception to setup.py to
> make it easier for the next guy
>
> if major=3D=3D2 and minor1<=3D3:
> =A0 =A0 # setuptools monkeypatches distutils.core.Distribution to support
> =A0 =A0 # package_data
> =A0 =A0 try: import setuptools
> =A0 =A0 except ImportError:
> =A0 =A0 =A0 =A0 raise SystemExit("""\
> matplotlib requires setuptools for installation. =A0Please download
> http://peak.telecommunity.com/dist/ez_setup.py and run it (as su if
> you are doing a system wide install) to install the proper version of
> setuptools for your system""")
Excellent, I was going to add a warning like this myself if the setuptools=
=20
approach was accepted.
> Darren, do you still have the html docs building on your system? =A0If
> so, perhaps you could update the installing page to mention the
> requirement (an perhaps the user's guide). =A0I updated the README in
> the src distro. =A0I still haven't got my build pipeline for the htdocs
> and user's guide going on my laptop after my old build computer died,
> a good indication that both are too complicated....
Yes, I am set up to build the html docs (in fact, I have been working a bit=
 on=20
the users guide this morning.) I'll update the webpage this afternoon.
Darren

On 2/23/07, Andrew Straw <str...@as...> wrote:
> 2) make our own distutils monkeypatch a la setuptools. Looking at
> setuptools/dist.py, this doesn't look trivial -- certainly beyond my
> free bandwidth capacity.
This is fine by me -- I actually was forced to think about this this
morning as I tried to upgrade my powerbook to the latest svn. I'm
still on python2.3, and when I tried to install I hit the setuptools
import. I figured I would be a good crash test dummy to see how easy
it was to install setuptools, so I poked around and found the ez_setup
and am off to the races. I added a friendly exception to setup.py to
make it easier for the next guy
if major==2 and minor1<=3:
 # setuptools monkeypatches distutils.core.Distribution to support
 # package_data
 try: import setuptools
 except ImportError:
 raise SystemExit("""\
matplotlib requires setuptools for installation. Please download
http://peak.telecommunity.com/dist/ez_setup.py and run it (as su if
you are doing a system wide install) to install the proper version of
setuptools for your system""")
Darren, do you still have the html docs building on your system? If
so, perhaps you could update the installing page to mention the
requirement (an perhaps the user's guide). I updated the README in
the src distro. I still haven't got my build pipeline for the htdocs
and user's guide going on my laptop after my old build computer died,
a good indication that both are too complicated....
JDH

On 3/3/07, Jouni K. Sepp=E4nen <jk...@ik...> wrote:
> Done. Should the function signature in the docstring of barh be
> changed as well? I think listing the possible keyword arguments and
> their defaults is valuable in the help text, but the signature could
> make people think they can use positional arguments.
The call signature in the docstring should certainly be changed to
match the new signature. Also, take a look at the kwdocd stuff we
have to see if you can make that work for the keyword args. See
Axes.plot for an example, where we interpolate the Line2D keyword arg
docstring into the __doc__ attribute.
Thanks,
JDH

"John Hunter" <jd...@gm...> writes:
>> I replaced most of the kwargs by a **kwargs dict in svn revision 3037.
>
> Since this changes the API, albeit minimally, make sure these changes
> are documented in the API_CHANGES file. Thanks for working on this.
Done. Should the function signature in the docstring of barh be
changed as well? I think listing the possible keyword arguments and
their defaults is valuable in the help text, but the signature could
make people think they can use positional arguments.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 3/3/07, Jouni K. Sepp=E4nen <jk...@ik...> wrote:
> I replaced most of the kwargs by a **kwargs dict in svn revision 3037.
> This does change the behavior for people who were giving positional
> arguments to barh, but they do get an error message.
Since this changes the API, albeit minimally, make sure these changes
are documented in the API_CHANGES file. Thanks for working on this.
JDH

Eric Firing <ef...@ha...> writes:
> Looks like barh just needs to take a **kwargs (which could replace most 
> of the present listed kwargs; or add a log kwarg to the list) and pass 
> it along to bar. You are taking care of this?
I replaced most of the kwargs by a **kwargs dict in svn revision 3037.
This does change the behavior for people who were giving positional
arguments to barh, but they do get an error message.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 3/2/07, Eric Firing <ef...@ha...> wrote:
> I didn't do it--but it looks like the reason is that having barh as a
> separate method permits a more natural order of arguments without
> introducing more complexity in the argument handling.
barh was originally added for compatibility with matlab and on a user
request. I think the kwarg was added to bar to support easy calling
for functions that use bar (eg hist) but may also want to configure
the orientation.

Jouni K. Seppänen wrote:
> Hi,
> 
> What is the reason for having both barh and bar, when the latter
> accepts the orientation='horizontal' argument? I am asking because of
> sf bug #1669506, which is about hist(orientation='horizontal') not
> working because it passes a log kwarg to barh.
> 
I didn't do it--but it looks like the reason is that having barh as a 
separate method permits a more natural order of arguments without 
introducing more complexity in the argument handling.
Vertical bars take left, height, width, bottom;
barh takes bottom, width, height, left.
Handling this difference with all possible combinations of *args and 
**kwargs would be complex; the present method, using a separate name 
(barh), is nice and simple.
Looks like barh just needs to take a **kwargs (which could replace most 
of the present listed kwargs; or add a log kwarg to the list) and pass 
it along to bar. You are taking care of this?
Eric

Hi,
What is the reason for having both barh and bar, when the latter
accepts the orientation='horizontal' argument? I am asking because of
sf bug #1669506, which is about hist(orientation='horizontal') not
working because it passes a log kwarg to barh.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

"John Hunter" <jd...@gm...> writes:
> Actually, I think I saved that in the freezer still in the envelope as
> a memento -- maybe I can just send that one on to save the dollar!
That sounds like something that could get me in trouble with Finnish
customs officials. I may have an opportunity to visit San Jose in
August -- that's at least on the same continent as you, right? :-)
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 3/1/07, Perry Greenfield <pe...@st...> wrote:
> What, you didn't like the way I did it? ;-)
Actually, I think I saved that in the freezer still in the envelope as
a memento -- maybe I can just send that one on to save the dollar!
JDH

On Mar 1, 2007, at 10:15 AM, John Hunter wrote:
> On 3/1/07, Jouni K. Sepp=E4nen <jk...@ik...> wrote:
>> I committed the following change, which seems to fix the bug.
>
>> - handles =3D ax.lines
>> + handles =3D ax.lines[:]
>
> Wow, nasty and subtle. Good work! Now how do I get a doughnut to you
> in Finland :-) Any ideas Perry?
What, you didn't like the way I did it? ;-)=

On 3/1/07, Jouni K. Sepp=E4nen <jk...@ik...> wrote:
> I committed the following change, which seems to fix the bug.
> - handles =3D ax.lines
> + handles =3D ax.lines[:]
Wow, nasty and subtle. Good work! Now how do I get a doughnut to you
in Finland :-) Any ideas Perry?
JDH

I committed the following change, which seems to fix the bug.
Index: legend.py
===================================================================
--- legend.py (revision 3031)
+++ legend.py (working copy)
@@ -315,7 +315,7 @@
 raise Exception, 'Auto legends not available for figure legends.'
 
 def get_handles(ax):
- handles = ax.lines
+ handles = ax.lines[:]
 handles.extend(ax.patches)
 handles.extend([c for c in ax.collections if isinstance(c, LineCollection)])
 
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

"John Hunter" <jd...@gm...> writes:
> I suspect we are screwing up somewhere in the way we copy properties
> from legended objects to their legend proxies (ie we are reversing
> this somewhere and copying properties from a proxy to the axes
Here's at least a clue: change your alphas from 0.5 to 0.1. Then
resize the window several times and watch the rectangles become 
a little bit darker each time. I suspect that extra copies of the
rectangles are being created.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks