Re: [matplotlib-devel] Any short plan for a new release (0.98.2 for real or 0.98.3)?
On Tue, Jul 22, 2008 at 6:30 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote:
> Chris: I've now added a griddata function to matplotlib.mlab that uses
> Robert Kern's scikit.delaunay code (which is now included in matplotlib
> as matplotlib.delaunay). The more bulletproof natgrid code, with the
> dubious license, is included as a toolkit (mpl_toolkits.natgrid), which
> griddata is configured to automatically use if installed.
Jeff, thanks for the extra effort to do it this way -- I know it was a
pain. But at least now we get
* commercial users can rely on our license as iron-clad
* griddata will work transparently out of the box for regular users
* we provide a path to the more bullet proof code for those who need it
I have a few comments I'll include below.
* Let's move the try/except natgrid/griddata import to the griddata
function itself so users not using griddata will not have to pay for
the import, since this will likely be 99% of the mpl users
* Expose griddata to the pylab interface and add it to the pylab and
mlab module doc strings
* We should provide some help for those who may want to try the
natgrid code, eg if you plan on releasing it on the sf site as a
toolkit, which I think is best, then we can link to the download page
in the docstring. If not, perhaps just provide an svn checkout line
for folks.
* Let's report which package is being used at the verbose helpful
level, preferably with some version info if it is available. When
questions come in on the mailing list later, we will want to know
which package griddata is using. You might set a flag on the griddata
function along the lines of
def griddata(blah)
if not griddata._reported:
if _use_natgrid:
verbose.report('using natgrid version blah')
else:
verbose.report('using delaunay version blah')
natgrid._reported = True
griddata._reported = False
* After the next release, let's remember to update the cookbook entry
- http://www.scipy.org/Cookbook/Matplotlib/Gridding_irregularly_spaced_data
Anyway, this is a great piece of additional functionality that we've
literally been waiting years for, so thanks for taking the extra time
to do it so thoroughly.
And enterprising developers everywhere, it would still be extremely
useful to follow Robert's suggestions to improve the delaunay code
along the lines discussed in this thread earlier. Not for the faint
of heart, but users for generations to come will thank you.
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)?
Christopher Barker wrote: > 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 > > > Chris: I've now added a griddata function to matplotlib.mlab that uses Robert Kern's scikit.delaunay code (which is now included in matplotlib as matplotlib.delaunay). The more bulletproof natgrid code, with the dubious license, is included as a toolkit (mpl_toolkits.natgrid), which griddata is configured to automatically use if installed. -Jeff - 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)?
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 - 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)?
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 [EMAIL PROTECTED] - 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: >> 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 [EMAIL PROTECTED] - 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: 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 - 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] 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] 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] 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)?
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)?
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 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)?
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)?
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 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] 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 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)?
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 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] 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] 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] Any short plan for a new release (0.98.2 for real or 0.98.3)?
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 - 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)?
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 - 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)?
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 <[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? >>> >>> >>> >> 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 >> Matplotlib-devel@lists.sourceforge.net >> 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 - 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)?
I'm looking into it. Cheers, Mike Andrew Straw wrote: > 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? >> >> > 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 > Matplotlib-devel@lists.sourceforge.net > 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 - 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?
>
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
#!/usr/bin/env python
"""
Example: simple line plots with NaNs inserted.
"""
from pylab import *
t = arange(0.0, 1.0+0.01, 0.01)
s = cos(2*2*pi*t)
t[41:60] = NaN
subplot(2,1,1)
plot(t, s, '-', lw=2)
xlabel('time (s)')
ylabel('voltage (mV)')
title('A sine wave with a gap of NaNs between 0.4 and 0.6')
grid(True)
subplot(2,1,2)
t[0] = NaN
t[-1] = NaN
plot(t, s, '-', lw=2)
xlabel('time (s)')
ylabel('voltage (mV)')
title('More NaNs at 0.0 and 1.0')
grid(True)
show()
-
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 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 - 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)?
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 <[EMAIL PROTECTED]> 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 - 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] Any short plan for a new release (0.98.2 for real or 0.98.3)?
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 - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
