Any short plan for a new release (0.98.2 for real or 0.98.3)?

Development matplotlib-devel
1

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.... :slight_smile:

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 :slight_smile:

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

2

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 <matrixhasu@...149...> 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.... :slight_smile:

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 :slight_smile:

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

3

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

···

On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <matrixhasu@...149...> 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).

4

John Hunter 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

nan_test.py (472 Bytes)

···

On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <matrixhasu@...149...> wrote:

5

I'm looking into it.

Cheers,
Mike

Andrew Straw wrote:

···

John Hunter wrote:
  

On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <matrixhasu@...149...> 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
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

6

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 <matrixhasu@...149...> 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
matplotlib-devel List Signup and Options
    
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

7

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

8

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

···

On Thu, Jul 17, 2008 at 08:55:59AM -0500, John Hunter wrote:

I think we could do a 0.98.3 release.

9

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

backend_detect.patch (701 Bytes)

···

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.

10

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

···

On Fri, Jul 18, 2008 at 2:04 AM, Gael Varoquaux <gael.varoquaux@...427...> 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.

11

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

···

On Fri, Jul 18, 2008 at 09:15:16AM -0500, John Hunter wrote:

12

John Hunter wrote:

···

On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <matrixhasu@...149...> 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 : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

13

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

···

On Fri, Jul 18, 2008 at 9:49 AM, Gael Varoquaux <gael.varoquaux@...427...> 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

14

I am more comfortable with this approach.

···

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...")?

15

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:

     Fast Robust Predicates for Computational Geometry

    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

···

On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <jswhit@...196...> wrote:

I'd like to see griddata functionality and Ryan May's wind barb patch in
0.98.3.

16

John Hunter 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:

     Fast Robust Predicates for Computational Geometry

    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

···

On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <jswhit@...196...> wrote:
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 : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

17

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

···

On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <jswhit@...196...> 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:

18

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.

···

On Fri, Jul 18, 2008 at 12:01, John Hunter <jdh2358@...149...> wrote:

On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <jswhit@...196...> 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.

--
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

19

Jeff Whitaker wrote:

John Hunter 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:

     Fast Robust Predicates for Computational Geometry

    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

···

On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <jswhit@...196...> wrote:

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 : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

20

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

···

On Fri, Jul 18, 2008 at 10:14:00AM -0500, John Hunter wrote: