Re: [OctDev] griddata / delaunay

[Jonathan S. <jjs...@sb...>]

OK, I see there has already been quite a bit of discussion and effort 
regarding the qhull based functions.  I still have 2 issues:

1.  Griddata is used for (linear) interpolation and, as such, should 
suffer not at all when using delaunay with the QJ option.  Let's 
implement this, please.  It is a very easy fix, as indicated in my patch 
for griddata.m at the beginning of this thread.

2.  Segfaults should never occur, but I have found an illustrative case 
where it does with delaunay.  I'll leave this to the experts.

Thanks,
Jonathan


Paul Kienzle wrote:
> See comments at:
> 
> http://www.octave.org/octave-lists/archive/help-octave.2003/ msg02420.html
> 
> and links therein.
> 
> - Paul
> 
> On Sep 1, 2004, at 7:09 PM, Jonathan Stickel wrote:
> 
>> Seems like a good solution to me.
>>
>> I'm rather new to open source development...  How do changes 
>> generally  get committed to octave-forge?  Should I submit a patch for 
>> delaunay  to this list?  Will someone then review and commit it?
>>
>> BTW:  I just started working with delaunay recently because griddata  
>> was giving me trouble.  I really don't know much about the other  
>> functions that use qhull, so I'd rather leave them alone right now.
>>
>> Thanks,
>> Jonathan
>>
>>
>> David Bateman wrote:
>>
>>> I'm not a user of delaunay and so you know better. I just proposed a  
>>> generic fix that should be applied wherever foreign code is used with
>>> octave to prevent just this type of problem. If the "QJ" to qhull is
>>> such a generic solution, why not just make the default for OPT in
>>> delaunay (and elsewhere?) be "QJ" with something like
>>>  if (nargin == 2)
>>>    opt = "QJ";
>>>  endif
>>> and be done with it. This combined with the previous fix, should be
>>> sufficient..
>>> D.