Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 07:36:03AM +0200, Gael Varoquaux wrote:
> On Thu, Jul 17, 2008 at 08:55:59AM -0500, John Hunter wrote:
> > I think we could do a 0.98.3 release.
> I am right now implementing a wx frontend to ipython, and I can see in
> the near future a score of people complaining that "from pylab import *;
> show()" crashes it because it calls the wrong backend. Do people mind if
> I prepare a patch that does some magic as pylab is loaded to:
> a) Look if 'wx' is in sys.module
> b) Check if the wx mainloop is running,
> and if so changes the backend automatically to wx and wxAgg.
OK, no replies tonight, so I went ahead and coded a patch, in the
interest of getting this in before the next release. It is attached.
Comments are welcome.
Gaël
Index: trunk/matplotlib/lib/matplotlib/pyplot.py
===
--- trunk/matplotlib/lib/matplotlib/pyplot.py (revision 5785)
+++ trunk/matplotlib/lib/matplotlib/pyplot.py (working copy)
@@ -32,7 +32,22 @@
MaxNLocator
+## Backend detection ##
+# If the wx Mainloop is started, starting another mainloop will crash
+# python, so we need to change to wx backend
+import sys
+if 'wx' in sys.modules:
+import wx
+if wx.App.IsMainLoopRunning():
+from matplotlib import rcParams, use
+if rcParams['backend'].endswith('Agg'):
+use('wxAgg')
+else:
+use('wx')
+
+
+
## Global ##
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Alpha Weirdness on Windows
Hi, Just a remark: GTKAgg on win32 is a combination I also use every day. And I think many people also use it. GTK is the almost only (nice) toolkit providing straightaway the same look and feel independantly of the platform used. This is very important if you would like to deploy the same software on an heterogeneous environment and you don't want users to rediscover the same software on different platforms. I personally prefer to use the "same" Gimp, whatever I'm in front of a Linux, Windows or Mac platform. And believe me or not, It happens almost everyday in my research environment where I have a Mac on my desk, windows platform controlling experiments, Unix stations running simulation softwares and a Linux when I come back home... Sorry for hijacking this thread, I was I bit chocked by John statement and wanted to react. All the best, David John Hunter a écrit : > On Thu, Jul 17, 2008 at 10:35 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Has anyone ever noticed weirdness with translucent polygons on win32 >> (using GTKAgg)? I had the occasion to actually do something on windows >> and noticed that, having drawn some polygons with alpha < 1, if I >> resized the window or panned, the alpha channel seemed to disappear and >> leave solid-colored polygons. > > gtkagg on win32 is a very unusual combination -- one I used a lot in > the day myself but it seems noone else did. It is really hard to > understand how something like this can happen from the way the code is > written, but yes, if you can get any insight into it, we'd certainly > like to understand and fix it. I have at least one fairly significant > piece of code that requires gtkagg on windows > > For starters, just posting the output of a script run with > --verbose-helpful so we can get some version info for the archives > will be useful. > > JDH > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] (Wind) Barbs
Ryan May wrote: > John Hunter wrote: >> On Tue, Jul 15, 2008 at 5:37 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> >>> I welcome any comments/criticism to help improve this. >> Hey Ryan, >> >> I have looked at this code briefly and have a few minor comments. I >> think Eric, who did the bulk of the current quiver implementation, and >> as an oceanographer is in a field much closer to yours than mine, will >> provide more useful feedback and should ultimately handle the patch >> submission. I would be happy to do so. >> >> My first comment is that the code looks very good -- it is well >> thought out and commented, and t is definitely suitable for inclusion >> in the main line. Certainly the Barbs class can live in the >> collections module. You note in the driver code that you are worried >> about pollution of the axes namespace by including a domain specific >> method, and this is a reasonable worry, but the axes namespace is >> currently so polluted with plotting methods that it is a small worry. >> I think it would be fine for you to rework your code into a patch >> which provides the Barbs collection in matplotlib.collections, an Axes >> method, and a pyplot interface function (with a pylab module level >> docstring entry). The overloading of the Axes namespace is not ideal, >> but it's what we've got. > > Thanks. My question then is how do I add a pyplot interface, since it > appears from the comments that many of those are just generated boilerplate? If all that is needed is a standard wrapper, then you add an entry to the appropriate list in boilerplate.py (which is in the root mpl directory, alongside CHANGELOG etc.), and run it to generate all the boilerplate, and then substitute that output for the corresponding chunk at the end of pyplot.py. (Or do some variation on this procedure that gives the same end result.) > >> My second comment has to do with your comment at the end of the example: >> >> #Showing colormapping with uniform grid. Unfortunately, only the flags >> #on barbs get colormapped this way. >> >> On a cursory read of the code, it looks like you have implemented >> everything as a single poly collection, and the reason the flags only >> get colored is that the varicolored is black. It seems like there are >> two solutions: write your class as a combination of poly collection >> (for the flags) and line collection (for the barbs) and colormap both >> (there are some line collection colormapping examples in the examples >> subdir courtesy of Eric). The 2nd alternative, which I haven't >> explored, is to set the edgecolor equal to the facecolor and support >> colormapping of the edgecolors. Isn't this already done? Here is a Collections method: def set_edgecolor(self, c): """ Set the edgecolor(s) of the collection. *c* can be a matplotlib color arg (all patches have same color), or a sequence or rgba tuples; if it is a sequence the patches will cycle through the sequence. If *c* is 'face', the edge color will always be the same as the face color. ACCEPTS: matplotlib color arg or sequence of rgba tuples """ if c == 'face': self._edgecolors = 'face' else: if c is None: c = mpl.rcParams['patch.edgecolor'] self._edgecolors = _colors.colorConverter.to_rgba_array(c, self._alpha) And in the draw method: if self._edgecolors == 'face': edgecolors = self._facecolors else: edgecolors = self._edgecolors renderer.draw_path_collection( transform.frozen(), self.clipbox, clippath, clippath_trans, paths, self.get_transforms(), offsets, transOffset, self._facecolors, edgecolors, self._linewidths, self._linestyles, self._antialiaseds) Am I missing something? (Probably--I have not looked very closely at barb yet.) Eric > > Yeah, the comment went more to explain expected results. There was no > mystery to me why the edgecolors didn't get colormapped, it was pretty > clear from the collections code. I had started down the road of > combining lines and polygons in a PatchCollection, but that created a > bunch of separate objects for each wind barb that had to each be > transformed and have an offset applied. I took the lazy way out and > created (admittedly) degenerate polygons. :) I hadn't actually thought > (call it a brain fart) about actually going ahead and adding > colormapping for the edgecolors. Should I follow Mike's suggestion and > possibly take a go at adding it to the general Collections class? > (Granted, if someone else took a stab at it, it might land in SVN > sooner, I'm sure I still have a learning curve to go here). > >> Overall this is very promising, and I wish you the best trying to make >> mpl serviceble to the meteorology community. Jeff Whitaker has done a >> phenomena
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi,
I just committed some changes to deal with these comments. Responses
below.
Cheers, David
On Thu, 2008-07-17 at 15:16 -0500, John Hunter wrote:
> def __init__(self, fig, eventslist=()):
> self.fig = fig
> assert isinstance(eventslist, tuple), "Requires a tuple of
> event name strings"
> self.eventslist = eventslist
>
> I would probably write a cbook method is_sequence_of_strings and just
> call that since it will be more readable and reusable...
>
Method added to cbook.
> I notice there are some residual print statements in the code -- these
> should be replaced by the verbose handler in matplotlib/__init__.py,
> eg in
>
> if timeout > 0 and counter > timeout/0.01:
> print "Timeout reached";
> break;
>
> and
> if self.verbose:
> print "input %i: %f,%f" % (len(self.clicks),
> event.xdata, event.ydata)
>
> and others in contour.py
>
> You can replace these with
>
> import matplotlib
> matplotlib.verbose.report('something')
>
> and
>
> matplotlib.verbose.report('some nitty gritty details', 'debug')
>
> There should be no prints in mpl.
>
Fixed.
> In contour.py, we have
>
> xmax = np.amax(np.array(linecontour)[:,0])
> xmin = np.amin(np.array(linecontour)[:,0])
> ymax = np.amax(np.array(linecontour)[:,1])
> ymin = np.amin(np.array(linecontour)[:,1])
I noticed these previously, but didn't touch them as this is in the part
of the code that is somewhat mysterious to me. linecontour should
always be an array (at least the linecontours in a Path), so I don't see
much point in forcing it to array. I have removed these and several
other np.array or np.asarray calls that seemed extraneous to me. If
desired, I can include a single np.array call, but I don't think it is
required.
Thanks,
David
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, On Thu, 2008-07-17 at 16:55 -0400, Paul Kienzle wrote: >FigureCanvasBase: >def start_event_loop(self, ...): >raise NotImplemented >FigureCanvasEventLoopMixin: >def start_event_loop(self, ...): >generic interactive using time.sleep >MyInteractiveBackend(FigureCanvasBase,FigureCanvasEventLoopMixin): >... no start_event_loop since using the generic mixin ... > So just to make sure that I understand this, "MyInteractiveBackend" would be any backend canvas class for whom we want to implement the standard generic mixin. For example, the class FigureCanvasGTK would inherit FigureCanvasEventLoopMixin until we get around to writing something specific for GTK. On the other hand, FigureCanvasWx wouldn't inherit the mixin, but would use the WX specific code you sent yesterday. And FigureCanvasPs wouldn't get anything at all. Am I getting this? If so, then I will go ahead and make the appropriate modifications. Looking at the list of backends, I think it suffices to inherit the mixin for the following backends: cairo, cocoagg, fltkagg?, gdk?, gtk, qt4, qt, tkagg (wx covered with its own code). All other interactive backends should inherit from these. The ones with the question marks I am not really sure about, but will assume true unless told otherwise. I agree with Gael that warning is probably sufficient. This will allow code running in the background to pass over interactive commands such as ginput. This may be better than an immediate error, but could cause problems later in the script when data is expected, but one gets []. Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 2:04 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > On Fri, Jul 18, 2008 at 07:36:03AM +0200, Gael Varoquaux wrote: >> On Thu, Jul 17, 2008 at 08:55:59AM -0500, John Hunter wrote: >> > I think we could do a 0.98.3 release. > >> I am right now implementing a wx frontend to ipython, and I can see in >> the near future a score of people complaining that "from pylab import *; >> show()" crashes it because it calls the wrong backend. Do people mind if >> I prepare a patch that does some magic as pylab is loaded to: >> a) Look if 'wx' is in sys.module >> b) Check if the wx mainloop is running, > >> and if so changes the backend automatically to wx and wxAgg. ipython Shell.py already hacks wx, gtk, and tk to make sure mpl's mainloop is not going to cause any problems (eg IPython.Shell.hijack_wx). Is there something about the new ipython wx frontend design that requires a different solution for mpl? I'm happy to hold the release until we get this sorted out, but before I review the patch maybe you can let me know what if anything is different about the new ipython design that requires changes in mpl because I haven't followed the ipython redesign closely enough. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Fri, Jul 18, 2008 at 4:27 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > So just to make sure that I understand this, "MyInteractiveBackend" > would be any backend canvas class for whom we want to implement the > standard generic mixin. For example, the class FigureCanvasGTK would > inherit FigureCanvasEventLoopMixin until we get around to writing > something specific for GTK. On the other hand, FigureCanvasWx wouldn't > inherit the mixin, but would use the WX specific code you sent > yesterday. And FigureCanvasPs wouldn't get anything at all. Am I > getting this? > > If so, then I will go ahead and make the appropriate modifications. > Looking at the list of backends, I think it suffices to inherit the > mixin for the following backends: cairo, cocoagg, fltkagg?, gdk?, gtk, > qt4, qt, tkagg (wx covered with its own code). All other interactive > backends should inherit from these. The ones with the question marks I > am not really sure about, but will assume true unless told otherwise. I'm not a huge fan of mixins. We use them occassionally, eg for FigureCanvasGtkAgg and their are some good uses for them, but they can quickly lead to overly complex code so should be avoided where possible. I find the "deeper hierarchy" approach more appealing here, but am not sure if it is viable. For example class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg) inherits from an interactive and a non-interactive backend, which is a good example of how quickly multiple mixin inheritance can get tricky. I think perhaps it is best to create no new classes, put the base methods in the FigureCanvasBase, make the default behavior non-interactive, and then overrride them for the GUI backends. Any problems with this? Finally, the term "interactive" is a bit confusing and overloaded here, since "is_interactive" in mpl means someone is working from the interactive shell and we want to update the figure on every command (if draw_if_interactive). For clarity, I think we should refer to this as a "user interface" backend or something like that,. I know in parts of the backend code we have the designation of interactive backends, but these variables should probably be renamed to avoid further confusion, since the other use of interactive is already enshrined in the frontend api and rc file. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Zero division bug in patches.py
Hi all!
I'm using version 0.91.2, but by looking at the svn repository is seems
this issue still exists.
There seems to be a bug in the getpoints() method in the YAArrow class.
When I execute the commands
from pylab import *
annotate('Oops...', (.2, .2), (.2, .6), arrowprops=dict(width=3))
show()
(note that the x2-x1==0) I get the error:
Traceback (most recent call last):
File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
line 331, in expose_event
self._render_figure(self._pixmap, w, h)
File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py",
line 75, in _render_figure
FigureCanvasAgg.draw(self)
File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 358, in draw
self.figure.draw(self.renderer)
File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
624, in draw
for a in self.axes: a.draw(renderer)
File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line
1345, in draw
a.draw(renderer)
File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line
1246, in draw
self.update_positions(renderer)
File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line
1242, in update_positions
**d)
File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
678, in __init__
verts = self.get_verts()
File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
690, in get_verts
xb1, yb1, xb2, yb2 = self.getpoints(x1, y1, x2, y2, k1)
File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
714, in getpoints
m = (y2-y1)/(x2-x1)
ZeroDivisionError: float division
Traceback (most recent call last):
File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
line 331, in expose_event
self._render_figure(self._pixmap, w, h)
File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py",
line 75, in _render_figure
FigureCanvasAgg.draw(self)
File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 358, in draw
self.figure.draw(self.renderer)
File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
624, in draw
for a in self.axes: a.draw(renderer)
File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line
1345, in draw
a.draw(renderer)
File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line
1246, in draw
self.update_positions(renderer)
File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line
1242, in update_positions
**d)
File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
678, in __init__
verts = self.get_verts()
File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
690, in get_verts
xb1, yb1, xb2, yb2 = self.getpoints(x1, y1, x2, y2, k1)
File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
714, in getpoints
m = (y2-y1)/(x2-x1)
ZeroDivisionError: float division
It seems that the function getpoints() doesn't take care of the
situations when the slope of the line (x1,y1,x2,y2) is zero or infinity.
This could be solved with the simple check in the function:
if y2-y1 == 0:
return x2, y2+k, x2, y2-k
elif x2-x1 == 0:
return x2+k, y2, x2-k, y2
This fixes it for me.
By the way, I just found out about matplotlib, and I find it extremely
useful! Thanks to all devs for creating this :).
Cheers,
Tuukka Verho
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Fri, Jul 18, 2008 at 3:50 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote:
>> I would probably write a cbook method is_sequence_of_strings and just
>> call that since it will be more readable and reusable...
>>
>
> Method added to cbook.
This method will return true on a string, which is probably not what you want
In [46]: is_sequence_of_strings('jdh was here')
Out[46]: True
My original example included an additional check on is_string_like(obj).
If you want to optionally support a string as a sequence of strings, I
think we might need a kwarg to make this explicit.
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 09:15:16AM -0500, John Hunter wrote: > ipython Shell.py already hacks wx, gtk, and tk to make sure mpl's > mainloop is not going to cause any problems (eg > IPython.Shell.hijack_wx). Is there something about the new ipython wx > frontend design that requires a different solution for mpl? Hum, maybe I am not understanding properly what you mean here. It acts on matplotlib only when it is passed the -pylab argument, AFAIK. Thus if you load "ipython -wthread" you will still be getting the default backend for matplotlib if you import it later on, and that default backend is GTK on Ubuntu, and the GTK mainloop doesn't play well at all with the wx one. > I'm happy to hold the release until we get this sorted out, but before > I review the patch maybe you can let me know what if anything is > different about the new ipython design that requires changes in mpl > because I haven't followed the ipython redesign closely enough. The frontend I am talking about is a PyShell replacement. It is a Wx widget and is not even multithreaded: it lives in the mainloop. We could indeed load pylab at the start and choose the right backend, but this requires preloading pylab, and I am not to enthousiastic about such a potential loss of time at load for users who have not asked for matlab. We could also provide a "-pylab" switch, but right now we don't even have a canonical entry point: this is a widget, and not a program. I'll talk to Fernando to have his view on this. The patch I have sent would also allow for seemless use of matplotlib in SPE, winpdb, or Mayavi, as all these apps use the wx mainloop. I hope this clarifies the situtation. Cheers, Gaël - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Zero division bug in patches.py
On Fri, Jul 18, 2008 at 9:31 AM, Tuukka Verho <[EMAIL PROTECTED]> wrote: > It seems that the function getpoints() doesn't take care of the > situations when the slope of the line (x1,y1,x2,y2) is zero or infinity. > This could be solved with the simple check in the function: > > if y2-y1 == 0: >return x2, y2+k, x2, y2-k > elif x2-x1 == 0: >return x2+k, y2, x2-k, y2 > > This fixes it for me. Thanks for the bug report and fix -- I've committed the changes to the 91 branch and the svn trunk. > > By the way, I just found out about matplotlib, and I find it extremely > useful! Thanks to all devs for creating this :). Glad you're liking it, and thanks for the help! JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
John Hunter wrote: > On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote: > >> Hi All, >> I'd like to "resubmit" the request below: any new version to be >> released soon? in the process to generate the doc in Debian, something >> got fixed upstream, so a new release would be really helpful to have >> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with >> strange chars in it). >> > > I think we could do a 0.98.3 release. There have been several bugs > fixed. Could you do me a favor and check svn r5722 and see if it > meets all your requirements for debian before we actually do the > release? > > Thanks, > JDH > > > I'd like to see griddata functionality and Ryan May's wind barb patch in 0.98.3. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 9:49 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > Hum, maybe I am not understanding properly what you mean here. It acts on > matplotlib only when it is passed the -pylab argument, AFAIK. Thus if you OK, at least I understand the issue now a bit better, thanks for explaining it. But I am not entirely comfortable with the solution. In general we have avoided trying to magically get stuff right in favor of making sure people are properly configured. This poses inconveniences to new users but at least allows people who are clear in their intentions to get what they want. I worry by forcing the backend to wx or wxagg just because wx has already been imported we are making too many assumptions (someone may want to use matplotlib pyplot in a wx app to generate pure image figures with the ps backend, etc...). We also now support custom external backends with the module://some_backend syntax so in principle one could be using a custom wx backend with a custom renderer outside of mpl. I'm sure there is a way to get what you want, but this may not be it. Basically, you want to support users who are using ipython -wthread but not -pylab who later import pylab with a misconfigured rc. Is this really desirable? Certainly you would want to trap this or warn or something so they don't get strange segfaults or other hard to diagnose errors, but automagically switching the backend in mpl may be too helpful in the way that microsoft windows is occassionally too helpful. What about checking to see if your ipython module is in sys.modules when pyplot is imported, checking the backend, and then importing it, checking for wthread etc, issuing a severe warning with known misconfigurations, eg gtkagg, with instructions on how to fix is (eg "your matplotlibrc file is here and the backend needs to be set to such-and-such...")? JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Friday 18 July 2008 11:14:00 am John Hunter wrote: > On Fri, Jul 18, 2008 at 9:49 AM, Gael Varoquaux > What about checking to see if your ipython module is in sys.modules > when pyplot is imported, checking the backend, and then importing it, > checking for wthread etc, issuing a severe warning with known > misconfigurations, eg gtkagg, with instructions on how to fix is (eg > "your matplotlibrc file is here and the backend needs to be set to > such-and-such...")? I am more comfortable with this approach. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: > I'd like to see griddata functionality and Ryan May's wind barb patch in > 0.98.3. OK things seem to be moving pretty fast right now on several fronts, so we may want to wait until mid next week before pushing anything out. Robert and I exchanged a few emails last night about his delaunay code. We have two choices on the dependency -- require an external scikits.delaunay that the user will install, or ship it *internally* in matplotlib, eg as matplotlib.delaunay (he is not too keen to see us repeat the mistakes we made with enthought.traits installing it ourselves externally). I prefer the matplotlib.delaunay solution since many win32, os x or naive users will not be comfortable with the svn download and source install. But Robert pointed out to me that one reason he has avoided pushing this further, eg into scipy, is that there are known degenerate cases arising from floating point precision issues that need to be worked out He wrote: My apologies, it does not segfault; it just returns an impossible triangulation. def test_slightly_degenerate(self): data = np.array([[-1, -1], [-1, 0], [-1, 1], [ 0, -1], [ 0, 0], [ 0, 1], [ 1, -1 - np.finfo(np.float_).eps], [ 1, 0], [ 1, 1], ]) tri = dlny.Triangulation(data[:,0], data[:,1]) I thought it possible that one of our developers may be interested in working on this, and he gave the following advice: Basically, Fortune's sweepline algorithm for Delaunay triangulation simply needs to be replaced with an algorithm that can be formulated using Jonathan Shewchuck's robust predicates: http://www.cs.cmu.edu/~quake/robust.html Divide and conquer or incremental insertion are reasonable candidates. Personally, I am willing to include the code in its current imperfect form in mpl with your griddata wrapper, provided that we make clear in the docstring that there are known degenerate cases (eg include Robert's example). Caveat emptor: this is an oft requested piece of code and I think many users would like to have something that works in most cases. But I think everyone would be well served by having a bullet-proof algorithm and Robert won't have time to work on this in the upcoming months, so perhaps one of us could spend some time looking at following Robert's suggestion and incorporating Jonathan Shewchuck's robust predicates into the implementation. So my advice is: let's fold the delaunay code into matplotlib.delaunay for 0.98.3 while providing copious warnings in your griddata interface, and get to work improving the algorithm for future releases, making sure we send Robert patches to the scikit.delaunay module if we manage to do anything useful so his implementation will remain the official branch as long as he wants it to be. If everyone agrees with this plan, I'll assume you'll take the lead on importing the code, and providing some examples/tests. And we can hold for Ryan's wind barbs too -- it looks like Eric is on the case. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Fri, Jul 18, 2008 at 11:27:50AM +0200, David M. Kaplan wrote:
> Hi,
>
> On Thu, 2008-07-17 at 16:55 -0400, Paul Kienzle wrote:
> >FigureCanvasBase:
> >def start_event_loop(self, ...):
> >raise NotImplemented
> >FigureCanvasEventLoopMixin:
> >def start_event_loop(self, ...):
> >generic interactive using time.sleep
> >MyInteractiveBackend(FigureCanvasBase,FigureCanvasEventLoopMixin):
> >... no start_event_loop since using the generic mixin ...
> >
>
> So just to make sure that I understand this, "MyInteractiveBackend"
> would be any backend canvas class for whom we want to implement the
> standard generic mixin. For example, the class FigureCanvasGTK would
> inherit FigureCanvasEventLoopMixin until we get around to writing
> something specific for GTK. On the other hand, FigureCanvasWx wouldn't
> inherit the mixin, but would use the WX specific code you sent
> yesterday. And FigureCanvasPs wouldn't get anything at all. Am I
> getting this?
Yes.
> If so, then I will go ahead and make the appropriate modifications.
> Looking at the list of backends, I think it suffices to inherit the
> mixin for the following backends: cairo, cocoagg, fltkagg?, gdk?, gtk,
> qt4, qt, tkagg (wx covered with its own code). All other interactive
> backends should inherit from these. The ones with the question marks I
> am not really sure about, but will assume true unless told otherwise.
$ grep -l button_press_event backends/*.py
backends/backend_cocoaagg.py
backends/backend_fltkagg.py
backends/backend_gtk.py
backends/backend_qt.py
backends/backend_qt4.py
backends/backend_template.py
backends/backend_tkagg.py
backends/backend_wx.py
> I agree with Gael that warning is probably sufficient. This will allow
> code running in the background to pass over interactive commands such as
> ginput. This may be better than an immediate error, but could cause
> problems later in the script when data is expected, but one gets [].
If exceptions aren't used, then non-interactive backends should
return [], and all calls to ginput should be checked:
x = ginput(3,timeout=2)
if len(x) < 3:
print "ginput only returned %d inputs"%(len(x))
Since users aren't going to remember to do this, it is better to
raise an exception so that they at least know later why their code
is breaking.
The current code has another problem in that timeouts will return
a partial list. This could be handle by raising RuntimeError in
ginput:
class BlockingInput:
...
def __call__(...):
...
if n > 0 and len(self.clicks) < n:
raise RuntimeError("Timeout when selecting inputs")
return self.clicks
If you want to get fancy and return the partial list of clicks,
this can be done with our own exception class:
--blocking_input.py--
class InputError(Exception):
def __init__(self, message, points):
self.message = message
self.points = points
class BlockingInput:
...
def __call__(...):
...
if n > 0 and len(self.clicks) < n:
raise InputError("Not enough inputs",self.clicks)
return self.clicks
Importing an extra symbol to catch the error would be ugly. I
suggest hiding it in the functions that need it instead:
--pyplot.py--
def ginput(*args, **kwargs):
...
ginput.InputError = matplotlib.blocking_input.InputError
This allows the pylab user to write:
try:
x = ginput(3,timeout=2)
except ginput.InputError,e:
print "ginput only returned %d inputs"%(len(e.points))
- Paul
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] updates to developer list
Periodically I go through the developer list and prune developers who
haven't made a commit in the last year, and was just reminded to do
this when I added David. This keeps the developers list down to a
reasonable size and makes it accurately reflect those who are
currently developing mpl. This is just a by-the-numbers decision,
we'd love to have any and all of you back, and I will be happy to
readd anyone who needs or wants to make commits, so just email me.
The user name and last commit date of those removed are listed below:
edin1 2007-07-16
kmcivor 2007-07-06
stevech 2007-07-08
teoliphant 2007-04-05
For the record books, here is the script I use to parse the svn logs:
import matplotlib.cbook as cbook
todate = cbook.todate('%Y-%m-%d')
border=''
last = dict()
for commit in file('log.out').read().split(border):
if not commit.strip():
continue
lines = commit.split('\n')
line = lines[1]
parts = [p.strip() for p in line.split('|')]
user = parts[1]
date = todate(parts[2][:10])
if user not in last:
last[user] = date
dsu = [(date, user) for user, date in last.items()]
dsu.sort()
for date, user in dsu:
print user, date
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
John Hunter wrote: > On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: > > >> I'd like to see griddata functionality and Ryan May's wind barb patch in >> 0.98.3. >> > > OK things seem to be moving pretty fast right now on several fronts, > so we may want to wait until mid next week before pushing anything > out. Robert and I exchanged a few emails last night about his > delaunay code. We have two choices on the dependency -- require an > external scikits.delaunay that the user will install, or ship it > *internally* in matplotlib, eg as matplotlib.delaunay (he is not too > keen to see us repeat the mistakes we made with enthought.traits > installing it ourselves externally). I prefer the matplotlib.delaunay > solution since many win32, os x or naive users will not be comfortable > with the svn download and source install. > > But Robert pointed out to me that one reason he has avoided pushing > this further, eg into scipy, is that there are known degenerate cases > arising from floating point precision issues that need to be worked > out > > He wrote: > > My apologies, it does not segfault; it just returns an impossible > triangulation. > >def test_slightly_degenerate(self): >data = np.array([[-1, -1], [-1, 0], [-1, 1], >[ 0, -1], [ 0, 0], [ 0, 1], >[ 1, -1 - np.finfo(np.float_).eps], [ 1, 0], [ 1, 1], >]) >tri = dlny.Triangulation(data[:,0], data[:,1]) > > > I thought it possible that one of our developers may be interested in > working on this, and he gave the following advice: > > Basically, Fortune's sweepline algorithm for Delaunay triangulation > simply needs to be replaced with an algorithm that can be formulated > using Jonathan Shewchuck's robust predicates: > > http://www.cs.cmu.edu/~quake/robust.html > > Divide and conquer or incremental insertion are reasonable candidates. > Personally, I am willing to include the code in its current imperfect > form in mpl with your griddata wrapper, provided that we make clear in > the docstring that there are known degenerate cases (eg include > Robert's example). Caveat emptor: this is an oft requested piece of > code and I think many users would like to have something that works in > most cases. But I think everyone would be well served by having a > bullet-proof algorithm and Robert won't have time to work on this in > the upcoming months, so perhaps one of us could spend some time > looking at following Robert's suggestion and incorporating Jonathan > Shewchuck's robust predicates into the implementation. > John: I concur with your plan. The triangulation algorithm used in the natgrid package is quite bulletproof. Unfortunately, it's GPL and I haven't been able to get NCAR to change the license. I checked Shewchuk's web page and unfortunately his code comes with this license: These programs may be freely redistributed under the condition that the copyright notices (including the copy of this notice in the code comments and the copyright notice printed when the `-h' switch is selected) are not removed, and no compensation is received. Private, research, and institutional use is free. You may distribute modified versions of this code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT IN THE SAME FILE REMAIN UNDER COPYRIGHT OF THE ORIGINAL AUTHOR, BOTH SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS. Distribution of this code as part of a commercial system is permissible ONLY BY DIRECT ARRANGEMENT WITH THE AUTHOR. (If you are not directly supplying this code to a customer, and you are instead telling them how they can obtain it for free, then you are not required to make any arrangement with me.) which is definitely not acceptable. I'll start to research other options ... > So my advice is: let's fold the delaunay code into matplotlib.delaunay > for 0.98.3 while providing copious warnings in your griddata > interface, and get to work improving the algorithm for future > releases, making sure we send Robert patches to the scikit.delaunay > module if we manage to do anything useful so his implementation will > remain the official branch as long as he wants it to be. If everyone > agrees with this plan, I'll assume you'll take the lead on importing > the code, and providing some examples/tests. > OK. -Jeff > And we can hold for Ryan's wind barbs too -- it looks like Eric is on the > case. > > JDH > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.Net email is sponsored by the Moblin Your Move D
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: > John: I concur with your plan. The triangulation algorithm used in the > natgrid package is quite bulletproof. Unfortunately, it's GPL and I haven't > been able to get NCAR to change the license. I checked Shewchuk's web page > and unfortunately his code comes with this license: Well there are two parts to his code. His triangulation code license is clearly unacceptable, but we could send Fernando over to talk to him (since Fernando is now at Berkeley too) about considering a license change. But his predicates code for orientation and incircle tests is in the public domain (http://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c). I think Robert was referring to incorporating these robust tests into his code rather than the actual triangle implementation, but perhaps he can clarify. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 12:01, John Hunter <[EMAIL PROTECTED]> wrote: > On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: > >> John: I concur with your plan. The triangulation algorithm used in the >> natgrid package is quite bulletproof. Unfortunately, it's GPL and I haven't >> been able to get NCAR to change the license. I checked Shewchuk's web page >> and unfortunately his code comes with this license: > > Well there are two parts to his code. His triangulation code license > is clearly unacceptable, but we could send Fernando over to talk to > him (since Fernando is now at Berkeley too) about considering a > license change. But his predicates code for orientation and incircle > tests is in the public domain > (http://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c). > I think Robert was referring to incorporating these robust tests into > his code rather than the actual triangle implementation, but perhaps > he can clarify. I meant that a Delaunay triangulation routine can be written using these public domain robust predicates. The current sweepline algorithm is not formulated to be able to use these predicates, so a different algorithm has to be implemented rather than simply incorporating the predicates into the current code. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
Jeff Whitaker wrote: > John Hunter wrote: > >> On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: >> >> >> >>> I'd like to see griddata functionality and Ryan May's wind barb patch in >>> 0.98.3. >>> >>> >> OK things seem to be moving pretty fast right now on several fronts, >> so we may want to wait until mid next week before pushing anything >> out. Robert and I exchanged a few emails last night about his >> delaunay code. We have two choices on the dependency -- require an >> external scikits.delaunay that the user will install, or ship it >> *internally* in matplotlib, eg as matplotlib.delaunay (he is not too >> keen to see us repeat the mistakes we made with enthought.traits >> installing it ourselves externally). I prefer the matplotlib.delaunay >> solution since many win32, os x or naive users will not be comfortable >> with the svn download and source install. >> >> But Robert pointed out to me that one reason he has avoided pushing >> this further, eg into scipy, is that there are known degenerate cases >> arising from floating point precision issues that need to be worked >> out >> >> He wrote: >> >> My apologies, it does not segfault; it just returns an impossible >> triangulation. >> >>def test_slightly_degenerate(self): >>data = np.array([[-1, -1], [-1, 0], [-1, 1], >>[ 0, -1], [ 0, 0], [ 0, 1], >>[ 1, -1 - np.finfo(np.float_).eps], [ 1, 0], [ 1, 1], >>]) >>tri = dlny.Triangulation(data[:,0], data[:,1]) >> >> >> I thought it possible that one of our developers may be interested in >> working on this, and he gave the following advice: >> >> Basically, Fortune's sweepline algorithm for Delaunay triangulation >> simply needs to be replaced with an algorithm that can be formulated >> using Jonathan Shewchuck's robust predicates: >> >> http://www.cs.cmu.edu/~quake/robust.html >> >> Divide and conquer or incremental insertion are reasonable candidates. >> Personally, I am willing to include the code in its current imperfect >> form in mpl with your griddata wrapper, provided that we make clear in >> the docstring that there are known degenerate cases (eg include >> Robert's example). Caveat emptor: this is an oft requested piece of >> code and I think many users would like to have something that works in >> most cases. But I think everyone would be well served by having a >> bullet-proof algorithm and Robert won't have time to work on this in >> the upcoming months, so perhaps one of us could spend some time >> looking at following Robert's suggestion and incorporating Jonathan >> Shewchuck's robust predicates into the implementation. >> >> > > John: I concur with your plan. The triangulation algorithm used in the > natgrid package is quite bulletproof. Unfortunately, it's GPL and I > haven't been able to get NCAR to change the license. I checked > Shewchuk's web page and unfortunately his code comes with this license: > > These programs may be freely redistributed under the condition that the > copyright notices (including the copy of this notice in the code comments > and the copyright notice printed when the `-h' switch is selected) are > not removed, and no compensation is received. Private, research, and > institutional use is free. You may distribute modified versions of this > code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT > IN THE SAME FILE REMAIN UNDER COPYRIGHT OF THE ORIGINAL AUTHOR, BOTH > SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND > CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS. Distribution of this code as > part of a commercial system is permissible ONLY BY DIRECT ARRANGEMENT > WITH THE AUTHOR. (If you are not directly supplying this code to a > customer, and you are instead telling them how they can obtain it for > free, then you are not required to make any arrangement with me.) > > which is definitely not acceptable. I'll start to research other > options ... > John: I just contacted NCAR again, and it seems that they have relicensed the software under an OSI-based license similar to the University of Illinois/NCSA: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Neither the names of NCAR's Computational and Information Systems Laboratory, the University Corporation for Atmospheric Research, nor the names of its contributors may be used to endorse or promote products derived from this Software without specific prior written permission. * Redistributions of source code must retain the above copyright notices, this list of conditions, and the disclaimer below. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the disclaimer below in the documentation
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 10:14:00AM -0500, John Hunter wrote: > Basically, you want to support users who are using ipython -wthread > but not -pylab who later import pylab with a misconfigured rc. That's ine way of putting it. You are considering the ipython, the way it is currently implemented is the only entry point to interactiv use of matplotlib. I think the is about to change significantly with the introduction of GUI frontends to ipython, that are not inheritely bound to pylab, like 'ipython -pylab' is. In fact Enthought has very short terms plans to make an IDE. > Is this really desirable? Certainly you would want to trap this or > warn or something so they don't get strange segfaults or other hard to > diagnose errors, but automagically switching the backend in mpl may be > too helpful in the way that microsoft windows is occassionally too > helpful. You have a point. I agree that my approach is not the good one, and is forcing too mcuh magic on the user. I will elaborate what might be a better solution below. > What about checking to see if your ipython module is in sys.modules > when pyplot is imported, checking the backend, and then importing it, > checking for wthread etc, issuing a severe warning with known > misconfigurations, eg gtkagg, with instructions on how to fix is (eg > "your matplotlibrc file is here and the backend needs to be set to > such-and-such...")? This is not about the wthread option. This is about embedding in a large GUI, whether it be the IDE I was mentionning, or winpdb, or SPE, or Mayavi. I don't think the current implementation is acceptable: you are requiring the users to change the backend depending on the eventloop they are running. Not only is this tedious, but it also require a fair amount of technical knowledge and exposes details (kind of event loop) that are irrelevent to the end user. Finally a lot of people will see the crash, and simply conclude that matplotib, or the interactive program they are runnning it from is buggy. We have had this come up more than once on the enthought-dev mailing list, and I wonder how many people simply never ask. OK, now what is the way forward. We need to provide the advanced-user for a good control on the backend. We need to provide a way that simply works without changing anything. The same code should run in "ipython -pylab", idle, or SPE. I think this means we need to add an rc entry. We could have two entries for backends: backend: auto or any of the current existing backend-default: any of the current existing If backend is set to auto, pyplot would check if an event loop is running and select the appriopriate backend. If no eventloop is running, it would use the backend specified in backend-default. This should work fairly nicely. The only think I am worried about is people changing the backend using matlplotlib.use, while rc['backend'] is still at auto, and then importing pyplot, which would change again the backend. Any suggestion for how to address that? Maybe matploib.use could put a flag somewhere, saying that it has been explicitely called. Internallythe plyplot magic to choose the backend would not set this flag. Comments? Gaël - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 12:52 PM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: > What do you think? If it's OK I say we use the natgrid package in > matplotlib, since it's more bulletproof than the scikits package (it passes > Robert's degenerate triangulation test, and has been pounded on by user of > NCAR graphics since the 1980's). Great work! I just contacted Jonathan with a similar query for Triangle, but am fully expecting a "no way" so very nice work on natgrid. The licensing terms look fine to me. Just drop the license in our licenses directory with some suitable name and fire away. Also make sure the license is included in the module docstring so we comply with the "redistribution in binary form" clause. In the unlikely event that Jonathan also comes back to us with a new license, we can decide then which is the better implementation. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
John Hunter wrote: > On Fri, Jul 18, 2008 at 12:52 PM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: > > >> What do you think? If it's OK I say we use the natgrid package in >> matplotlib, since it's more bulletproof than the scikits package (it passes >> Robert's degenerate triangulation test, and has been pounded on by user of >> NCAR graphics since the 1980's). >> > > Great work! I just contacted Jonathan with a similar query for > Triangle, but am fully expecting a "no way" so very nice work on > natgrid. The licensing terms look fine to me. Just drop the license > in our licenses directory with some suitable name and fire away. Also > make sure the license is included in the module docstring so we comply > with the "redistribution in binary form" clause. In the unlikely > event that Jonathan also comes back to us with a new license, we can > decide then which is the better implementation. > > JDH > John: Well, I hit one snag. One file in natgrid has this comment in it. /* * The code in this file is based on code written and * copyrighted (C) by Dave Watson. Dr. Watson retains the * copyright to his original code. Augmentations and changes * to Dr. Watson's code are copyrighted (C) by UCAR, 1997. */ The NCAR folks have not been able to contact the fellow, and suspect he may have passed on. I can't verify this though. Do you see this as a problem? -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi,
My bad - I forgot strings are iterable. This should now be fixed.
Cheers,
David
On Fri, 2008-07-18 at 09:41 -0500, John Hunter wrote:
> On Fri, Jul 18, 2008 at 3:50 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote:
>
> >> I would probably write a cbook method is_sequence_of_strings and just
> >> call that since it will be more readable and reusable...
> >>
> >
> > Method added to cbook.
>
> This method will return true on a string, which is probably not what you want
>
> In [46]: is_sequence_of_strings('jdh was here')
> Out[46]: True
>
> My original example included an additional check on is_string_like(obj).
>
> If you want to optionally support a string as a sequence of strings, I
> think we might need a kwarg to make this explicit.
>
> JDH
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi,
On Fri, 2008-07-18 at 11:52 -0400, Paul Kienzle wrote:
> If exceptions aren't used, then non-interactive backends should
> return []
>
I think I have changed my mind on this one - an error seems more
appropriate. The real-world use cases for this are (1) someone doesn't
realize they are in a non-user-interface backend and runs ginput and (2)
someone is running in the background a script that contains interactive
elements. In both cases, using these functions is almost certainly an
error on the users side and it is impossible to decide what the user
would like to have returned in this case. If the user really wants
potentially non-interactive run of the code, he could use try, except to
deal with that.
> The current code has another problem in that timeouts will return
> a partial list. This could be handle by raising RuntimeError in
> ginput:
>
> class BlockingInput:
> ...
> def __call__(...):
> ...
> if n > 0 and len(self.clicks) < n:
> raise RuntimeError("Timeout when selecting inputs")
> return self.clicks
>
> If you want to get fancy and return the partial list of clicks,
> this can be done with our own exception class:
>
> --blocking_input.py--
> class InputError(Exception):
> def __init__(self, message, points):
> self.message = message
> self.points = points
> class BlockingInput:
> ...
> def __call__(...):
> ...
> if n > 0 and len(self.clicks) < n:
> raise InputError("Not enough inputs",self.clicks)
> return self.clicks
>
> Importing an extra symbol to catch the error would be ugly. I
> suggest hiding it in the functions that need it instead:
>
> --pyplot.py--
> def ginput(*args, **kwargs):
> ...
> ginput.InputError = matplotlib.blocking_input.InputError
>
> This allows the pylab user to write:
>
> try:
> x = ginput(3,timeout=2)
> except ginput.InputError,e:
> print "ginput only returned %d inputs"%(len(e.points))
>
> - Paul
>
For ginput, there are a number of ways that an impartial list could be
returned and this is often a desired outcome (for example, I often
decide after the fact that I want fewer points than I initially
thought). Perhaps as a compromise we could set the default timeout to
-1 so the user needs to actually choose a timeout (presumably indicating
he/she accepts the consequences). But allowing the user to manually
decide to select fewer points using the second mouse button has proved
quite useful to me and the user would still need to test in this case.
We could warn if not enough points are returned, but an error seems too
much to me.
Cheers,
David
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, On Fri, 2008-07-18 at 09:24 -0500, John Hunter wrote: > On Fri, Jul 18, 2008 at 4:27 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > I'm not a huge fan of mixins. We use them occassionally, eg for > FigureCanvasGtkAgg and their are some good uses for them, but they can > quickly lead to overly complex code so should be avoided where > possible. I find the "deeper hierarchy" approach more appealing here, > but am not sure if it is viable. For example > > class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg) > Actually the case of GTKAgg is an interesting one. I have FigureCanvasGTK inherit the mixin, but this doesn't cascade to GTKAgg because it gets overloaded with the non-user-interface versions from FigureCanvasAgg leading calls to ginput to produce an error. Adding the mixin to the end of GTKAgg's inheritance list didn't work because it seems that python decides that Agg has already overwritten the same mixin included by GTK and ignores the mixin inheritance at the end of the list (this surprised me, but it appears to work that way). One could always force it to use the right ones by adding functions that point to the mixin versions, but this seems less elegant than inheritance. In this and similar cases, is the order of inheritance important? Changing it to (FigureCanvasAgg, FigureCanvasGTK) should fix the problem. > inherits from an interactive and a non-interactive backend, which is a > good example of how quickly multiple mixin inheritance can get tricky. > I think perhaps it is best to create no new classes, put the base > methods in the FigureCanvasBase, make the default behavior > non-interactive, and then overrride them for the GUI backends. Any > problems with this? > Well, yeah. I think this would mean a lot of the same code in many backends. I also like the idea of a deeper hierarchy with a FigureCanvasUserInterface class that inherits FigureCanvasBase but adds functional start/stop_loop_events because it would allow for a simple cbook test for a working user interface: isinstance(mycanvas,FigureCanvasUserInterface) A deeper hierarchy won't help the inheritance problem for GTKAgg though. > Finally, the term "interactive" is a bit confusing and overloaded > here, since "is_interactive" in mpl means someone is working from the > interactive shell and we want to update the figure on every command > (if draw_if_interactive). For clarity, I think we should refer to > this as a "user interface" backend or something like that,. I know in > parts of the backend code we have the designation of interactive > backends, but these variables should probably be renamed to avoid > further confusion, since the other use of interactive is already > enshrined in the frontend api and rc file. > I agree. > JDH -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Alpha Weirdness on Windows
John Hunter wrote: > On Thu, Jul 17, 2008 at 10:35 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Has anyone ever noticed weirdness with translucent polygons on win32 >> (using GTKAgg)? I had the occasion to actually do something on windows >> and noticed that, having drawn some polygons with alpha < 1, if I >> resized the window or panned, the alpha channel seemed to disappear and >> leave solid-colored polygons. > > gtkagg on win32 is a very unusual combination -- one I used a lot in > the day myself but it seems noone else did. It is really hard to > understand how something like this can happen from the way the code is > written, but yes, if you can get any insight into it, we'd certainly > like to understand and fix it. I have at least one fairly significant > piece of code that requires gtkagg on windows > > For starters, just posting the output of a script run with > --verbose-helpful so we can get some version info for the archives > will be useful. Well what was real enough yesterday, today I can't reproduce. Maybe it was just some windows weirdness. I'll let you know if I see it again (but I'm not sure that I'll have any reason to be doing much on windows in the near future.) Sorry for the noise. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Fri, Jul 18, 2008 at 09:17:02PM +0200, David M. Kaplan wrote: > For ginput, there are a number of ways that an impartial list could be > returned and this is often a desired outcome (for example, I often > decide after the fact that I want fewer points than I initially > thought). Can't you use ginput(0) for these cases? It doesn't work on Mac with no middle mouse button to terminate the sequence, but that is a separate issue. > Perhaps as a compromise we could set the default timeout to > -1 so the user needs to actually choose a timeout (presumably indicating > he/she accepts the consequences). But allowing the user to manually > decide to select fewer points using the second mouse button has proved > quite useful to me and the user would still need to test in this case. > We could warn if not enough points are returned, but an error seems too > much to me. The cases I'm thinking about (e.g., select fit range) have a specific number of points. Other cases (e.g., select shape outline) have an indefinite number of points. I can't think of case off hand where I would want e.g., six or fewer points. That said, I can always wrap the function in my own interface for my scripts. - Paul - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] hexbin and nans
I just spent a little time getting hexbin to discard nans without
failing in mysterious ways.
I'm sending 2 patches: one will detect nans and raise a suitable
exception. The other will automatically drop the nans and continue with
hexbin. The 2nd seems a little nicer in functionality, but the code is a
little more convoluted and hence more brittle, and so I'm torn as to
which I'd prefer. (The problem with just detecting nans from the
beginning is that it would cause an extra pass through the data in all
cases.)
Anyhow, I've attached them both here for discussion. I'm happy to check
one of these in myself or feel free to do it.
-Andrew
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 5789)
+++ lib/matplotlib/axes.py (working copy)
@@ -5106,6 +5106,8 @@
xmax = np.amax(x)
ymin = np.amin(y)
ymax = np.amax(y)
+if np.any(np.isnan((xmin,xmax,ymin,ymax))):
+raise ValueError('input arrays cannot have nan')
# In the x-direction, the hexagons exactly cover the region from
# xmin to xmax. Need some padding to avoid roundoff errors.
padding = 1.e-9 * (xmax - xmin)
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 5789)
+++ lib/matplotlib/axes.py (working copy)
@@ -5099,13 +5099,33 @@
x = np.array(x, float)
y = np.array(y, float)
if xscale=='log':
+orig_x = x
x = np.log10(x)
if yscale=='log':
+orig_y = y
y = np.log10(y)
xmin = np.amin(x)
xmax = np.amax(x)
ymin = np.amin(y)
ymax = np.amax(y)
+
+# This allows us to detect nans and re-start without making an
+# additional pass through the data. (Ideally, we would pick
+# this up in delete_masked_points(), but that would require an
+# additional loop through the arrays.)
+if np.any(np.isnan((xmin,xmax,ymin,ymax))):
+if xscale=='log':
+x = orig_x # reverse x scaling done above
+if yscale=='log':
+y = orig_y # reverse y scaling done above
+x = np.ma.masked_where( np.isnan(x), x)
+y = np.ma.masked_where( np.isnan(y), y)
+return self.hexbin(x, y, gridsize = gridsize, bins = bins,
+ xscale = xscale, yscale = yscale,
+ cmap=cmap, norm=norm, vmin=vmin, vmax=vmax,
+ alpha=alpha, linewidths=linewidths, edgecolors=edgecolors,
+ **kwargs)
+
# In the x-direction, the hexagons exactly cover the region from
# xmin to xmax. Need some padding to avoid roundoff errors.
padding = 1.e-9 * (xmax - xmin)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] gtkagg backend main() not stopping after all windows closed
It appears the current svn trunk has a problem in that gtk.main() in backend_gtk.py line 71 never returns, even after all windows have been closed. To reproduce, run "python simple_plot.py -dGTKAgg" and close the window. This does not happen with WXAgg or TkAgg. -Andrew - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
John Hunter wrote: > > And we can hold for Ryan's wind barbs too -- it looks like Eric is on the > case. It's at the top of my list ATM. I've let this afternoon get away from me, but I have literally *nothing* to do tomorrow and Sunday, so expect a patch this weekend. (Let's hope I haven't jinxed myself here.) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] gtkagg backend main() not stopping after all windows closed
On Fri, Jul 18, 2008 at 3:00 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > It appears the current svn trunk has a problem in that gtk.main() in > backend_gtk.py line 71 never returns, even after all windows have been > closed. To reproduce, run "python simple_plot.py -dGTKAgg" and close the > window. This does not happen with WXAgg or TkAgg. Arg, while trying to debug another problem I commented out a relevant line and forgot to uncomment. Should be fixed in 5790. Thanks for the report. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Fri, Jul 18, 2008 at 07:57:25PM +0200, Gael Varoquaux wrote: > OK, now what is the way forward. We need to provide the advanced-user for > a good control on the backend. We need to provide a way that simply works > without changing anything. The same code should run in "ipython -pylab", > idle, or SPE. I think this means we need to add an rc entry. We could > have two entries for backends: > backend: auto or any of the current existing > backend-default: any of the current existing > If backend is set to auto, pyplot would check if an event loop is running > and select the appriopriate backend. If no eventloop is running, it would > use the backend specified in backend-default. > This should work fairly nicely. The only think I am worried about is > people changing the backend using matlplotlib.use, while rc['backend'] is > still at auto, and then importing pyplot, which would change again the > backend. Any suggestion for how to address that? Maybe matploib.use could > put a flag somewhere, saying that it has been explicitely called. > Internallythe plyplot magic to choose the backend would not set this > flag. I talk to Fernando about this, and he came up with a suggestion I like quite a lot. The idea would be to give an "backend_fallback" boolean in the rc parameters. When loading an interactive backend, if this boolean is set to true (by default), the backend-loading code would check that the proposed interactive backend is complatible with the current running mainloop, and if not walk the different backends to find a suitable one, without shooting a warning at the user, because the user should not have to know about this. I think this is a good way of satisfying both the requirement for seemless operation in different event loops and the requirement for advanced users that can control completely how things happen using the rc parameter switch. Moreover, if there is not risk of conflict, the rc-specified choice would be kept. What do you think? Where should I insert this code? Cheers, Gaël - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hexbin and nans
On Fri, Jul 18, 2008 at 2:49 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > I just spent a little time getting hexbin to discard nans without > failing in mysterious ways. > > I'm sending 2 patches: one will detect nans and raise a suitable > exception. The other will automatically drop the nans and continue with > hexbin. The 2nd seems a little nicer in functionality, but the code is a > little more convoluted and hence more brittle, and so I'm torn as to > which I'd prefer. (The problem with just detecting nans from the > beginning is that it would cause an extra pass through the data in all > cases.) I think the nans should be dropped with no raise or warning, which is consistent with our handling elsewhere. I don't think your approach, which if I am reading this correctly assumes that is x or y has nans then the min or max will be nan, is correct. Eg, In [51]: x = np.random.rand(10) In [52]: x[4] = np.nan In [53]: x.min() Out[53]: 0.37072898459621617 In [54]: x.max() Out[54]: 0.79367039009185769 I think min and max in the presence of nans is undefined. But you can just pay for the extra pass mask = np.isnan(x) & np.isnan(y) if mask.any(): # mask where JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hexbin and nans
John Hunter wrote: > On Fri, Jul 18, 2008 at 2:49 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > >> I just spent a little time getting hexbin to discard nans without >> failing in mysterious ways. >> >> I'm sending 2 patches: one will detect nans and raise a suitable >> exception. The other will automatically drop the nans and continue with >> hexbin. The 2nd seems a little nicer in functionality, but the code is a >> little more convoluted and hence more brittle, and so I'm torn as to >> which I'd prefer. (The problem with just detecting nans from the >> beginning is that it would cause an extra pass through the data in all >> cases.) >> > > I think the nans should be dropped with no raise or warning, which is > consistent with our handling elsewhere. I don't think your approach, > which if I am reading this correctly assumes that is x or y has nans > then the min or max will be nan, is correct. Eg, > > In [51]: x = np.random.rand(10) > > In [52]: x[4] = np.nan > > In [53]: x.min() > Out[53]: 0.37072898459621617 > > In [54]: x.max() > Out[54]: 0.79367039009185769 > > > I think min and max in the presence of nans is undefined. True -- that slipped past me, since in my use case the nans were always coming out for both min and max... > But you can > just pay for the extra pass > > mask = np.isnan(x) & np.isnan(y) > if mask.any(): > # mask where If you're happy with that extra cost, I'll modify axes.delete_masked_points() so that hexbin and scatter are automatically filtered in this way. Given the speed complaints we sometimes get, I was hesitant to add another pass through the data. -Andrew - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hexbin and nans
On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > If you're happy with that extra cost, I'll modify > axes.delete_masked_points() so that hexbin and scatter are automatically > filtered in this way. Given the speed complaints we sometimes get, I was > hesitant to add another pass through the data. Happy is the wrong word -- we certainly should make these things as efficient as reasonable so if your optimization worked it would be preferable numpy passes are rarely the bottleneck but they are good to be aware of. We could provide some helper function in nxutils to do more stuff in a single pass for common use cases (eg a minmax function to get both the min and the max...) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hexbin and nans
John Hunter wrote: > On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > >> If you're happy with that extra cost, I'll modify >> axes.delete_masked_points() so that hexbin and scatter are automatically >> filtered in this way. Given the speed complaints we sometimes get, I was >> hesitant to add another pass through the data. masks.extend([~np.isfinite(x) for x in args]) may be the quickest and most general way to do it. I believe ~np.isfinite is both more general and significantly faster than np.isnan. A kwarg could be used to enable or disable this checking. Eric > > Happy is the wrong word -- we certainly should make these things as > efficient as reasonable so if your optimization worked it would be > preferable numpy passes are rarely the bottleneck but they are good > to be aware of. We could provide some helper function in nxutils to > do more stuff in a single pass for common use cases (eg a minmax > function to get both the min and the max...) > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hexbin and nans
Eric Firing wrote:
> John Hunter wrote:
>> On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <[EMAIL PROTECTED]>
>> wrote:
>>
>>> If you're happy with that extra cost, I'll modify
>>> axes.delete_masked_points() so that hexbin and scatter are automatically
>>> filtered in this way. Given the speed complaints we sometimes get, I was
>>> hesitant to add another pass through the data.
>
> masks.extend([~np.isfinite(x) for x in args])
>
> may be the quickest and most general way to do it. I believe
> ~np.isfinite is both more general and significantly faster than np.isnan.
Clever, but it won't work as-is. np.isfinite('b') returns a
NotImplementedType, and a default argument to scatter is c='b', which
gets passed to this function. Anyhow, I implemented your idea with a
check for NotImplementedType and some unit tests in r5791.
> A kwarg could be used to enable or disable this checking.
Yes, but since we're grabbing *args, that would mean parsing **kwargs --
so I just implemented it without the option of disabling it. I'm happy
to add this if desired.
>> Happy is the wrong word -- we certainly should make these things as
>> efficient as reasonable so if your optimization worked it would be
>> preferable numpy passes are rarely the bottleneck but they are good
>> to be aware of. We could provide some helper function in nxutils to
>> do more stuff in a single pass for common use cases (eg a minmax
>> function to get both the min and the max...)
Yes, good idea. (In fact I wonder why numpy doesn't have minmax.) And
apologies for suggesting that you might be "happy" with a (minor)
slowdown -- not the best choice of words.
-Andrew
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hexbin and nans
On Fri, Jul 18, 2008 at 4:17 PM, Andrew Straw <[EMAIL PROTECTED]> wrote: > Yes, good idea. (In fact I wonder why numpy doesn't have minmax.) I've often wondered this myself... Cheers, f - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Matplotlib and latest numpy
Hi, Am I wrong, or does matploib not build with current numpy svn? Here is the error message I am getting: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/home/varoquau/dev/numpy/trunk/numpy/core/include -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/ft2font.cpp -o build/temp.linux-i686-2.5/src/ft2font.o cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++ In file included from /home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/arrayobject.h:14, from src/ft2font.cpp:6: /home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/ndarrayobject.h:17:25: error: numpyconfig.h: No such file or directory /home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/ndarrayobject.h:1829:30: error: __multiarray_api.h: No such file or directory src/ft2font.cpp: In member function ‘Py::Object FT2Image::py_as_array(const Py::Tuple&)’: src/ft2font.cpp:273: error: ‘PyArray_Type’ was not declared in this scope src/ft2font.cpp:273: error: ‘PyArray_New’ was not declared in this scope src/ft2font.cpp: In function ‘void initft2font()’: src/ft2font.cpp:1877: error: ‘import_array’ was not declared in this scope error: command 'gcc' failed with exit status 1 If you look at the numpy/core/include/numpy/ndarrayobject.h file, it says clearly at the top of the file "do not include this file directly". Gaël - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib and latest numpy
On Sat, Jul 19, 2008 at 01:25:51AM +0200, Gael Varoquaux wrote: > Am I wrong, or does matploib not build with current numpy svn? OK, Fernando told me that matplotlib builds fine with latest numpy on his box so Ienquired a bit more. The problem is that the build of matplotlib tries to include a header file that is generated automatically during the build of numpy (__multiarray_api.h). If you install numpy using "python setup.py install", this header file is inlcuded in the install. However I used "python setupegg.py develop" to install numpy. As a result the header file does not get put in the include directory. I guess this is thus a bug in the setupegg.py of numpy, but my knowledge of setuptools is way to low to be able to fix that. Cheers, Gaël - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Progress on interactive backend detection
I have implemented a prototype of interactive backend detection. As I
proposed earlier, I added an extra rc parameter 'backend_fallback' that
allows pyplot to inspect sys.modules on load and try to redirect
interactive backends to the appropriate ones.
I am attaching a patch, not for inclusion, as I still want to check
different details on interactivity, and the behavior of the show command,
but for comments and triage. I have tested it in various apps, and I
think it is interesting to review the different mainstream apps
presenting a interactive shell in which pylab can be used interactively.
* wx apps. In mayavi2, my near-born ipython frontend the attached patch
works seamlessly, with or without the interactive switch. In SPE
(wx-based IDE) it does not work, and I suspect this is because of ugly
things SPE does to the wx image-loading, for theming reasons, as I see
totally unrelated errors.
* Qt: In Eric4 the qt detection does not work as it seems that Eric
spawns a new python process. As a result, as long as you keep the
interactive switch off, pylab works great, but you really have to use a
blocking show. Does anybody now a Qt program that has an interactive
Python prompt?
* In IDLE I can't figure out what is happening. I must confess that I do not
know much about Tkinter, and I am not too sure how matplotlib is
supposed to collaborate with an existing Tk mainloop.
* The only GTK program I could think of with an interactive python prompt
was accerciser, an pylab now works out of the box there, in interactive
mode or not.
Of course in ipython -q|q4|w|g-thread, my addition work seamlessly, but
that was too easy :).
Some remarks that came out of this extensive testing:
- show starts a mainloop and is blocking even if there are not windows
open. This basically leads to a deadlock where the user cannot
interrupt the mainloop. This can probably be easily fixed, and I'll
look into it.
- we cannot guess whether the user want to be in interactive mode or
not: there is a potential large cost of being in interactive mode due to
continuous refreshing of the UI. Ipython gets it right by turning the
interactive mode off when running a script, but when need the host
environment to make this decision and we cannot make it in matplotlib.
However, I believe it is important to expose more this
functionality, as the user will now probably have to make this
decision. This is why I have add the import of "interactive" in
pyplot.
- this brings up the fact that the user experience can be increased a
lot if the host environment collaborates with matplotlib. This is why
we discussed with John the idea of adding a "vendor registry", a
light-weight module that an environment could import at little cost
to tell matplotlib what backend to use, whether to put the
interactive switch, and hopefully more, like maybe a factory to
create new figure, as this would allow embedding these figures in an IDE.
We do this with mayavi2, where the figures created by mlab are
standalone windows when the fullblown environment is not running, but
integrated windows when it is running.
I am sure there is more that we can learn. Please come up with ideas so
that we can see better what is the way forward for integrating matplotlib
to graphical shells and environments.
Cheers,
Gaël
Index: trunk/matplotlib/lib/matplotlib/pyplot.py
===
--- trunk/matplotlib/lib/matplotlib/pyplot.py (revision 5785)
+++ trunk/matplotlib/lib/matplotlib/pyplot.py (working copy)
@@ -32,7 +32,22 @@
MaxNLocator
+## Backend detection ##
+# If the wx Mainloop is started, starting another mainloop will crash
+# python, so we need to change to wx backend
+import sys
+if 'wx' in sys.modules:
+import wx
+if wx.App.IsMainLoopRunning():
+from matplotlib import rcParams, use
+if rcParams['backend'].endswith('Agg'):
+use('wxAgg')
+else:
+use('wx')
+
+
+
## Global ##
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Progress on interactive backend detection
I forgot to mention: fltk and cocoa did not get any love at all in this patch. The reason being that I do not know of any program running the first one, and for me to test and develop things for the second one, somebody will have to offer me an apple computer :). Cheers, Gaël - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Progress on interactive backend detection
On Sat, Jul 19, 2008 at 07:31:19AM +0200, Gael Varoquaux wrote:
> - show starts a mainloop and is blocking even if there are not windows
> open. This basically leads to a deadlock where the user cannot
> interrupt the mainloop. This can probably be easily fixed, and I'll
> look into it.
It turns out it was only in the GTK backend, and quite trivial to
correct. Attached is a new patch, including this correction.
Gaël
Index: pyplot.py
===
--- pyplot.py (revision 5791)
+++ pyplot.py (working copy)
@@ -1,12 +1,13 @@
import sys
import matplotlib
-from matplotlib import _pylab_helpers
+from matplotlib import _pylab_helpers, interactive
from matplotlib.cbook import dedent, silent_list, is_string_like, is_numlike
from matplotlib.figure import Figure, figaspect
from matplotlib.backend_bases import FigureCanvasBase
from matplotlib.image import imread as _imread
from matplotlib import rcParams, rcParamsDefault, get_backend
+from matplotlib.rcsetup import interactive_bk as _interactive_bk
from matplotlib.artist import getp, get, Artist
from matplotlib.artist import setp as _setp
from matplotlib.axes import Axes
@@ -32,7 +33,41 @@
MaxNLocator
+## Backend detection ##
+def _backend_selection():
+""" If rcParams['backend_fallback'] is true, check to see if the
+current backend is compatible with the current running event
+loop, and if not switches to a compatible one.
+"""
+backend = rcParams['backend']
+if not rcParams['backend_fallback'] or \
+ backend not in _interactive_bk:
+return
+is_agg_backend = rcParams['backend'].endswith('Agg')
+if 'wx' in sys.modules and not backend in ('WX', 'WXAgg'):
+import wx
+if wx.App.IsMainLoopRunning():
+rcParams['backend'] = 'wx' + 'Agg' * is_agg_backend
+elif 'qt' in sys.modules and not backend == 'QtAgg':
+import qt
+if not qt.qApp.startingUp():
+# The mainloop is running.
+rcParams['backend'] = 'qtAgg'
+elif 'PyQt4.QtCore' in sys.modules and not backend == 'Qt4Agg':
+import PyQt4.QtGui
+if not PyQt4.QtGui.qApp.startingUp():
+# The mainloop is running.
+rcParams['backend'] = 'qt4Agg'
+elif 'gtk' in sys.modules and not backend in ('GTK', 'GTKAgg',
+'GTKCairo'):
+import gobject
+if gobject.MainLoop().is_running():
+rcParams['backend'] = 'gtk' + 'Agg' * is_agg_backend
+elif 'Tkinter' in sys.modules and not backend == 'TkAgg':
+import Tkinter
+_backend_selection()
+
## Global ##
from matplotlib.backends import pylab_setup
Index: backends/backend_gtk.py
===
--- backends/backend_gtk.py (revision 5791)
+++ backends/backend_gtk.py (working copy)
@@ -67,7 +67,8 @@
for manager in Gcf.get_all_fig_managers():
manager.window.show()
-if mainloop and gtk.main_level() == 0:
+if mainloop and gtk.main_level() == 0 and \
+len(Gcf.get_all_fig_managers())>0:
gtk.main()
def new_figure_manager(num, *args, **kwargs):
Index: rcsetup.py
===
--- rcsetup.py (revision 5791)
+++ rcsetup.py (working copy)
@@ -305,6 +305,7 @@
# a map from key -> value, converter
defaultParams = {
'backend' : ['Agg', validate_backend], # agg is certainly present
+'backend_fallback' : [True, validate_bool], # agg is certainly present
'numerix' : ['numpy', validate_numerix],
'maskedarray' : [False, validate_bool],
'toolbar' : ['toolbar2', validate_toolbar],
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
