On 20-Jan-1997, Shmuel Tomer <

[hidden email]> wrote:

: In matlab:

:

: >> [1 2] == [1]

:

: ans =

:

: 1 0

:

: >> [1 2] == []

:

: ans =

:

: 0

:

: but in octave:

:

: octave:1> [1 2] == [1]

: ans =

:

: 1 0

:

: octave:2> [1 2] == []

: error: operator ==: nonconformant arguments (op1 is 1x2, op2 is 0x0)

:

: Is this a bug or a feature?

I think I would call this a bug.

: In other words, would it be correct to reverse the order of the

: following two tests in the macro MX_MX_BOOL_OP (src/ops.h, lines

: 94-100)?

:

: if (m1_nr != m2_nr || m1_nc != m2_nc) \

: { \

: gripe_nonconformant ("operator " op, m1_nr, m1_nc, m2_nr, m2_nc); \

: return Matrix (); \

: } \

: if (m1_nr == 0 || m1_nc == 0) \

: return empty_result; \

:

: Would that have (disastrous) effects, other than to provide a Matlab

: compatible behavior?

I don't think that simply switching the order of the tests is enough

to make this part of Octave compatible with Matlab. I've just posted

a patch to the bug-octave mailing list that might do a better job.

: I don't prefer this behavior per se, but being able to use octave in

: my site may depend on wheter the users need to go through the

: existing zillion scripts and change every occurrence of

:

: if myString == ''

: to

: if strcmp(myString, '')

The patch will also make

myString == ''

work as you expect.

Thanks,

jwe