From: Sandro T. <mat...@gm...> - 2008-07-02 11:46:23
|
Hi guys, in Debian we finally find a nice way to let the documentation be compiled at package build-time so we are ready for a "real" new release of matplotlib (more that the source-only you kindly provided me last week), so when you're ready.... :) For sure, I won't upload a new one in the next 2/3 days or so, because I want to let 0.98.1 transit from unstable to testing (the Debian staging area used to release lenny), so from the weekend on I'd be glad to upgrade matplotlib and bother the release team to include it in the next release :) Thank a lot for the great support you gave/giving me, Sandro -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
From: Sandro T. <mat...@gm...> - 2008-07-17 12:48:11
|
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'm lookgin forward to heard back from you soon. Thanks in advance, Sandro On Wed, Jul 2, 2008 at 13:46, Sandro Tosi <mat...@gm...> wrote: > Hi guys, > in Debian we finally find a nice way to let the documentation be > compiled at package build-time so we are ready for a "real" new > release of matplotlib (more that the source-only you kindly provided > me last week), so when you're ready.... :) > > For sure, I won't upload a new one in the next 2/3 days or so, because > I want to let 0.98.1 transit from unstable to testing (the Debian > staging area used to release lenny), so from the weekend on I'd be > glad to upgrade matplotlib and bother the release team to include it > in the next release :) > > Thank a lot for the great support you gave/giving me, > Sandro -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
From: John H. <jd...@gm...> - 2008-07-17 13:56:03
|
On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> 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 |
From: Andrew S. <str...@as...> - 2008-07-17 17:08:38
Attachments:
nan_test.py
|
John Hunter wrote: > On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> 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? > I just checked r5772 and found that a problem when plotting nans. I know that masked arrays are preferred to nans, but considering that this used to work in 0.91 and earlier, this is a regression. I've modified nan_test.py in examples/pylab_examples to illustrate the bug in r5773 (also attached), but I think Eric would probably be vastly more efficient than I when it comes to fixing properly. -Andrew |
From: Michael D. <md...@st...> - 2008-07-17 17:22:24
|
I'm looking into it. Cheers, Mike Andrew Straw wrote: > John Hunter wrote: > >> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> 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? >> >> > I just checked r5772 and found that a problem when plotting nans. I know > that masked arrays are preferred to nans, but considering that this used > to work in 0.91 and earlier, this is a regression. > > I've modified nan_test.py in examples/pylab_examples to illustrate the > bug in r5773 (also attached), but I think Eric would probably be vastly > more efficient than I when it comes to fixing properly. > > -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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: Michael D. <md...@st...> - 2008-07-17 17:41:27
|
Should be fixed in r5775. It seems Agg doesn't like MOVETO commands and the end of a path. Since the update is in a C++ header file, you will need to force a full rebuild (by removing your build directory, for instance.) Cheers, Mike Michael Droettboom wrote: > I'm looking into it. > > Cheers, > Mike > > Andrew Straw wrote: > >> John Hunter wrote: >> >> >>> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> 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? >>> >>> >>> >> I just checked r5772 and found that a problem when plotting nans. I know >> that masked arrays are preferred to nans, but considering that this used >> to work in 0.91 and earlier, this is a regression. >> >> I've modified nan_test.py in examples/pylab_examples to illustrate the >> bug in r5773 (also attached), but I think Eric would probably be vastly >> more efficient than I when it comes to fixing properly. >> >> -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 >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
From: Andrew S. <str...@as...> - 2008-07-17 18:36:10
|
Michael Droettboom wrote: > Should be fixed in r5775. > > It seems Agg doesn't like MOVETO commands and the end of a path. Since > the update is in a C++ header file, you will need to force a full > rebuild (by removing your build directory, for instance.) Thanks, I tested and this fixes the issue for me. -Andrew |
From: Jeff W. <js...@fa...> - 2008-07-18 15:12:02
|
John Hunter wrote: > On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> 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/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: John H. <jd...@gm...> - 2008-07-18 15:40:06
|
On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <js...@fa...> 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 |
From: Jeff W. <js...@fa...> - 2008-07-18 16:50:07
|
John Hunter wrote: > On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <js...@fa...> 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/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Jeff W. <js...@fa...> - 2008-07-18 18:27:41
|
John Hunter wrote: > On Fri, Jul 18, 2008 at 12:52 PM, Jeff Whitaker <js...@fa...> 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/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |
From: Robert K. <rob...@gm...> - 2008-07-19 22:42:22
|
Jeff Whitaker wrote: > 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? It was for me. That's why I wrote scikits.delaunay in the first place. That, and the nngridr code's an uncommented mass of nested ifs. -- 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 |
From: Christopher B. <Chr...@no...> - 2008-07-21 18:27:30
|
Jeff Whitaker wrote: >> 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 great idea. > I checked > Shewchuk's web page and unfortunately his code comes with this license: ... How I wish people would just pick a known Open Source License -- it's not like there are a shortage of them! Might it be worth a note to Shewchuk asking him if we can put it in MPL? -- though it doesn't look promising. Fortunately, his Robust Predicate code is, I think, in the public domain, or a more flexible license anyway. We've got some robust code in-house that does it all in integers, though that does limit your options. It's based on Knuth's work in: Axioms and Hulls by Donald E. Knuth (Heidelberg: Springer-Verlag, 1992), ix+109pp. (Lecture Notes in Computer Science, no. 606.) ISBN 3-540-55611-7 http://www-cs-faculty.stanford.edu/~knuth/aah.html Anyone know of any other code based on that work? Nice to see this moving forward, though -- thanks, everyone! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Robert K. <rob...@gm...> - 2008-07-21 19:52:07
|
Christopher Barker wrote: > Jeff Whitaker wrote: >> I checked >> Shewchuk's web page and unfortunately his code comes with this license: > > ... > > How I wish people would just pick a known Open Source License -- it's > not like there are a shortage of them! Might it be worth a note to > Shewchuk asking him if we can put it in MPL? -- though it doesn't look > promising. Because he (or his institution's technology transfer department) wants to forbid commercial use without paying them money. He doesn't want Triangle to be open source. -- 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 |
From: Christopher B. <Chr...@no...> - 2008-07-21 18:40:41
|
arrg! When am I going to learn not to click "send" until after I've read the entire thread! Jeff Whitaker wrote: > 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: ... > 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). that would be nice, but while it is a good solution to the re-gridding problem, it doesn't appear to provide a general purpose delauney triangulation solution, which is too bad -- it would be nice to have that in MPL. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Ryan M. <rm...@gm...> - 2008-07-18 20:19:02
|
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 |
From: Gael V. <gae...@no...> - 2008-07-18 05:36:21
|
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. I could not sleep and do this tonight to get it ready for the release, but I would like people's feedback... (Famous last words) Gaël |
From: Gael V. <gae...@no...> - 2008-07-18 07:04:36
Attachments:
backend_detect.patch
|
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 |
From: John H. <jd...@gm...> - 2008-07-18 14:15:20
|
On Fri, Jul 18, 2008 at 2:04 AM, Gael Varoquaux <gae...@no...> 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 |
From: Gael V. <gae...@no...> - 2008-07-18 14:49:20
|
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 |
From: John H. <jd...@gm...> - 2008-07-18 15:14:05
|
On Fri, Jul 18, 2008 at 9:49 AM, Gael Varoquaux <gae...@no...> 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 |
From: Darren D. <dsd...@gm...> - 2008-07-18 15:25:28
|
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. |
From: John H. <jd...@gm...> - 2008-07-18 17:01:22
|
On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <js...@fa...> 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 |
From: Robert K. <rob...@gm...> - 2008-07-18 17:08:57
|
On Fri, Jul 18, 2008 at 12:01, John Hunter <jd...@gm...> wrote: > On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <js...@fa...> 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 |
From: Jeff W. <js...@fa...> - 2008-07-18 17:52:43
|
Jeff Whitaker wrote: > John Hunter wrote: > >> On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <js...@fa...> 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 and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE SOFTWARE. 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). -Jeff > >> 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/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg |