bug in conv()

[Ben Abbott]

On Sep 29, 2008, at 2:14 AM, Jaroslav Hajek wrote:

> On Mon, Sep 29, 2008 at 2:59 AM, Ben Abbott <bpabbott at mac.com> wrote:
>>
>> On Sep 28, 2008, at 4:47 PM, dph.work wrote:
>>
>>> According to http://www.gnu.org/software/octave/FAQ.html#MATLAB-compatibility
>>> differences in Matlab and Octave are considered bugs.  The attached
>>> m file
>>> illustrates how conv() produces a column vector in Matlab and a row
>>> vector in
>>> Octave.
>>>
>>> Hope this helps.
>>> Dan
>>>
>>> % In Matlab the variable c ends up a column vector, while in  
>>> Octave it
>>> % ends up a row vector.
>>> %
>>> % octave:9> conv_bug.m
>>> % ans =
>>> %
>>> %    1   29
>>> %octave:9> ver
>>> %
>>> %
>>> ----------------------------------------------------------------------
>>> % GNU Octave Version 3.0.1
>>> % GNU Octave License: GNU General Public License
>>> % Operating System: Linux 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53
>>> % CEST 2007 x86_64
>>> %
>>> ----------------------------------------------------------------------
>>>
>>> % matlab>> conv_bug
>>> %
>>> % ans =
>>> %
>>> %    29     1
>>> %
>>> %matlab>> ver
>>> %
>>> -----------------------------------------------------------------------
>>> % MATLAB Version 7.3.0.298 (R2006b)
>>> % MATLAB License Number:
>>> % Operating System: Linux 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53
>>> % CEST 2007 x86_64
>>> % Java VM Version: Java is not enabled
>>> %
>>> -----------------------------------------------------------------------
>>> % MATLAB                                     Version 7.3
>>> (R2006b)
>>> % Signal Processing Toolbox                  Version 6.6
>>> (R2006b)
>>>
>>> a = blackman(10);
>>> b = blackman(20);
>>> c = conv(a,b);
>>>
>>> size(c)
>>
>> The default branch (3.1.51+) respects Matlab's behavior. However,
>> 3.0.2 fails.
>>
>> Question for the list; As 3.0.3 is soon to be released, should that  
>> be
>> fixed?
>>
>> Ben
>>
>
> The conv.m sources are not differing betheen the two branches.
> Apparently the problem is in DLD-FUNCTIONS/filter.cc, but according to
> ChangeLog, the only relevant patch missing from 3.0.x is John's 7967,
> adding single precision type, which apparently fixes the problem as a
> side effect. So this will stay unfixed until someone isolates the fix
> for 3.0.x.

ok. I did a bit more testing. Matlab's output vector respects the  
input vector of greatest length. I'm also confused was to what I did  
yesterday. Today, I don't detect any difference between 3.0.2 and  
3.1.51+ :-(

In any event, I've added the following tests to my local version of  
conv.m

%!test
%! a = 1:10;
%! b = 1:3;
%! c = conv (a, b);
%! assert (size(c), [1, numel(a)+numel(b)-1])
%!test
%! a = (1:10).';
%! b = 1:3;
%! c = conv (a, b);
%! assert (size(c), [numel(a)+numel(b)-1, 1])
%!test
%! a = 1:10;
%! b = (1:3).';
%! c = conv (a, b);
%! assert (size(c), [1, numel(a)+numel(b)-1])

In 3.0.2 I get

> octave:26> test conv
>   ***** xtest
>  a = (1:10).';
>  b = 1:3;
>  c = conv (a, b);
>  assert (size(c), [numel(a)+numel(b)-1, 1])
> !!!!! known failure
> error: assert (size (c),[numel(a) + numel(b) - 1, 1]) expected
>    12    1
> but got
>     1   12
> values do not match
> PASSES 9 out of 9 tests (1 expected failures)

In 3.1.51+ I get

> octave-3.1.51+:21> test conv
>   ***** xtest
>  a = (1:10).';
>  b = 1:3;
>  c = conv (a, b);
>  assert (size(c), [numel(a)+numel(b)-1, 1])
> !!!!! known failure
> assert (size (c),[numel(a) + numel(b) - 1, 1]) expected
>    12    1
> but got
>     1   12
> values do not matchPASSES 9 out of 9 tests (1 expected failures)


So it appears that the orientation is a bug in all versions. I'm  
unfamiliar with filter(), I'll look to see if the problem is there or  
local to conv.m.

Also, notice the output of "test" for 3.1.51+ ... the last two lines  
are missing a LF.

Ben