[Octave-bug-tracker] [bug #61295] cross() dimensions inconsistent with Matlab when using mismatched input vector dimensions

[Nicholas Jankowski]

Follow-up Comment #2, bug #61295 (group octave):

testing in matlab 2023b

no dim input:

>> x = 1:3; y = 2:4;
>> cross (x,y) % row, row
ans =
    -1     2    -1
>> cross (x',y') % col, col
ans =
    -1
     2
    -1
>> cross (x',y) % col, row
ans =
    -1     2    -1
>> cross (x,y') % row, col
ans =
    -1     2    -1

>> x = 1:3; y = 2:4;
>> cross (x,y) % row, row

ans =

    -1     2    -1

so output is a row except for 'col,col", which outputs a column. with dim
input and mismatched vectors, e.g., cross(x,y',1), you get a size mismatch
error for any combination, as one of the dims don't have size 3:

>> cross (x',y,1) % col, row
Error using cross
A and B must be of length 3 in the dimension in which the cross product is
taken.


current octave behavior (using current stable):

>> x = 1:3;y=2:4;
>> cross (x,y) % row, row
ans =

  -1   2  -1

>> cross (x',y') % col, col
ans =

  -1
   2
  -1

>> cross (x,y') % row, col
warning: cross: taking cross product of row by column
warning: called from
    cross at line 78 column 7

ans =

  -1
   2
  -1

>> cross (x',y) % col, row
warning: cross: taking cross product of column by row
warning: called from
    cross at line 75 column 7

ans =

  -1
   2
  -1

so we do the opposite, defaulting to a col. Octave also catches the mismatch
with dim specified and issues an error.

i also assume the fact that we have a compatibility hack to specifically
address this indicates they made a col->row switch at some point. Our hack to
match now causes an incompatibility.  could be an inadvertent effect of some
other change they made for underlying functions working on vectors. seemed to
be a lot of them in the ~2018 timeframe.

So, options here:
(1) leave it alone, advise that inputs should pass size_equal(x,y) for
predictable/compatible behavior, and document the potential incompatibility.
(2) switch the undocumented compatibility hack to be compatible, making them
row vectors. it's simple enough to change what is transposed. this could break
some octave backward compatibility but improve cross-compatibility.
(3) absent any documentation we remove the hack, just throw a size mismatch
error, and stop trying to copy undocumented behavior.  this would break both
cross and backward compatibility. advise that inputs must pass size_equal

(i may still peek through release notes/bugfix reports to see if i can
pinpoint a change. that would at least be some documentation to go on)


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61295>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/