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

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

···

On Fri, Jul 18, 2008 at 12:52 PM, Jeff Whitaker <jswhit@...196...> 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).

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

···

On Fri, Jul 18, 2008 at 12:52 PM, Jeff Whitaker <jswhit@...196...> wrote:

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

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

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

···

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.

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

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:

     Fast Robust Predicates for Computational Geometry

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

Chris.Barker@...236...

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

Chris.Barker@...236...

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

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

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

···

On Tue, Jul 22, 2008 at 6:30 AM, Jeff Whitaker <jswhit@...196...> 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.