bug in __lin_interpn__.cc for decreasing coordinates

David Bateman adb014 at gmail.com
Mon Jan 21 16:50:24 CST 2008


Alexander Barth wrote:
> On Jan 21, 2008 2:26 PM, David Bateman <David.Bateman at motorola.com> wrote:
> 
>>
>>
>> Alexander Barth wrote:
>>> Hi all again,
>>> this code,
>>>
>>> [x,y,z] = ndgrid(0:2);
>>> f = x.^2+y.^2+z.^2;
>>> fi = interpn(x,y,-z,f,1.5,1.5,-1.5)
>>>
>>> returns NA (octave 3.0.0) while the correct answer is 7.5. The
>>> attached patch, handles the case for decreasing coordinate values in
>>> __lin_interpn__.cc
>>>
>>> Proposed changelog:
>>> __lin_interpn__.cc: handle decreasing coordinate values
>>>
>>> Thanks,
>>> Alex
>>>
>> Its a bit hard to read your patch due to changes in the tabulation.
>> Though this is your code, and it addresses a real issue, so I'm all for
>> applying it..
>>
>> D.
>>
> 
> yes, the tabulation was changed since I changed:
> 
> previous_code
> 
> to
> 
> if (increasing)
>    {
>       previous_code
>    }
> else
>    {
>       new_code
>    }
> 
> but the patch should not change the indentation style. Is it
> preferable to use the diff option "--ignore-space-change" in this case
> ?

Humm, to make it easier to read yes.. But then someone has to go through
and redo the indentation after the patch is applied, so that's not great
either. There is nothing apart from my laziness from stopping me from
applying the patch and regenerating a patch ignoring whitespace myself.
So my preference would be to have patches that have the indentation
changes included as that is less work in the long run..

D.


More information about the Bug-octave mailing list