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 and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 
IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR 
ANY CLAIM, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR 
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR 
THE USE OR OTHER DEALINGS WITH THE SOFTWARE.

What do you think?  If it's OK I say we use the natgrid package in 
matplotlib, since it's more bulletproof than the scikits package (it 
passes Robert's degenerate triangulation test, and has been pounded on 
by user of NCAR graphics since the 1980's).

-Jeff


>   
>> So my advice is: let's fold the delaunay code into matplotlib.delaunay
>> for 0.98.3 while providing copious warnings in your griddata
>> interface, and get to work improving the algorithm for future
>> releases, making sure we send Robert patches to the scikit.delaunay
>> module if we manage to do anything useful so his implementation will
>> remain the official branch as long as he wants it to be.  If everyone
>> agrees with this plan, I'll assume you'll take the lead on importing
>> the code, and providing some examples/tests.
>>   
>>     
>
> OK.
>
> -Jeff
>   
>> And we can hold for Ryan's wind barbs too -- it looks like Eric is on the 
>> case.
>>
>> JDH
>>   
>>     
>
>
>   


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : [EMAIL PROTECTED]
325 Broadway                Office : 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

Reply via email to