conv does not preverve orientation of input

[Moritz Borgmann-2]

In Octave, the orientation of the output of y = conv(a,b) is always a
row vector. In Matlab, the rules are the following:

  - if a is shorter or equal in size to b: orientation of y is the same as b
  - if b is shorter than a: orientation of y is same as a.

Wuut. You may or may not believe it, but there's code that depends on
this behavior. Find attached a patch that "fixes" conv.m.

Test cases are included.

-M

[John W. Eaton]

On 28-Mar-2008, Moritz Borgmann wrote:

| In Octave, the orientation of the output of y = conv(a,b) is always a
| row vector. In Matlab, the rules are the following:
|
|   - if a is shorter or equal in size to b: orientation of y is the same as b
|   - if b is shorter than a: orientation of y is same as a.
|
| Wuut. You may or may not believe it, but there's code that depends on
| this behavior.

Why would this be desirable?

| Find attached a patch that "fixes" conv.m.
|
| Test cases are included.

I'd like to hear from others before making this change.

jwe

[Moritz Borgmann-2]

>On 28-Mar-2008, Moritz Borgmann wrote:
>
>| In Octave, the orientation of the output of y = conv(a,b) is always a
>| row vector. In Matlab, the rules are the following:
>|
>|   - if a is shorter or equal in size to b: orientation of y is the same as b
>|   - if b is shorter than a: orientation of y is same as a.
>|
>| Wuut. You may or may not believe it, but there's code that depends on
>| this behavior.
>
>Why would this be desirable?

well, writing code that makes assumptions like this is of course not
desirable. At least I wouldn't do it. In this case, I discovered code
written by others, with fairly wide distribution, that failed in a
very subtle manner because it expected Matlab behavior. In fact, it
only assumed that the output orientation was the same as the
orientation of a long input vector "b", where "a" was a short
coefficient vector.

In a sense, Octave's behavior is also arbitrary (or am I overlooking
some general practice that tells us to always return row vectors?).
Considering this and given that there's no silver bullet, I figured
it would be the least evil to support the mode of operation that code
may expect from Matlab.

-M

[Jaroslav Hajek-2]

On Fri, Mar 28, 2008 at 8:52 PM, John W. Eaton <jwe@...> wrote:

> On 28-Mar-2008, Moritz Borgmann wrote:
>
>  | In Octave, the orientation of the output of y = conv(a,b) is always a
>  | row vector. In Matlab, the rules are the following:
>  |
>  |   - if a is shorter or equal in size to b: orientation of y is the same as b
>  |   - if b is shorter than a: orientation of y is same as a.
>  |
>  | Wuut. You may or may not believe it, but there's code that depends on
>  | this behavior.
>
>  Why would this be desirable?
>
>
>  | Find attached a patch that "fixes" conv.m.
>  |
>  | Test cases are included.
>
>  I'd like to hear from others before making this change.
>
>  jwe
>

I would vote against mimicking such quirks. This behaviour is not even
documented in Matlab; therefore, code relying on it is unreliable
anyway, IMHO - things may change in future version,
because more users can see this as a bug rather than feature. (Me, for
instance. I'm much more interested in Octave than Matlab now, but if I
ever find time and if I remember, I think I may report it, because I
reckon it's useless behaviour).
Octave's behaviour is fine if "row vector" is substituted for "vector"
in the docstring, although
it would perhaps be better if it returned column vector when both args
are column vectors, for instance, by taking the orientation from the
first argument. In any case, the rule should be documented and it
should be simple and useful.
 I think there are more functions with identical problem (deconv, for instance).

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz