bug still present in Octave 8.0.1.

I'd wager Lachlan's 2016 patch will no longer apply cleanly. Is the approach sufficiently satisfactory to make it it worth revisiting and trying to refresh?

behavior still present in Octave 5.2.0

Appears to still be relevant.

Matlab 2017a:

>> ones(2,3)*ones(3,1)

ans =

     3
     3

>> ones(2,3)*ones(3,1,2)
Error using  *
Arguments must be 2-D, or at least one argument must be scalar. Use TIMES (.*) for elementwise
multiplication.

>> ones(2,3)*ones(3,1,2,2)
Error using  *
Arguments must be 2-D, or at least one argument must be scalar. Use TIMES (.*) for elementwise
multiplication.

>> ones(2,3)*ones(3,1,2,2,2)
Error using  *
Arguments must be 2-D, or at least one argument must be scalar. Use TIMES (.*) for elementwise
multiplication.

Octave 4.2.1:

>> ones(2,3)*ones(3,1)
ans =

   3
   3

>> ones(2,3)*ones(3,1,2)
ans =

   3   3
   3   3

>> ones(2,3)*ones(3,1,2,2)
ans =

   3   3   3   3
   3   3   3   3

>> ones(2,3)*ones(3,1,2,2,2)
ans =

   3   3   3   3   3   3   3   3
   3   3   3   3   3   3   3   3

I'm attaching a patch, and the shell+awk scripts I used to generate it.

The operators are created by a maze of nested macros to minimize repeated code.  It may be able to be simplified using templates, but my guess is that it would still require quite a bit of special-case code.  For example "A * B'" doesn't just transpose B and then multiply; it uses a particular library call that performs them together.  Multiplication by a sparse, diagonal or permutation matrix clearly needs different code from multiplication by a full matrix etc.

This is right in the heart of Octave, and so it will probably take a lot of time and testing to get the patch approved.  Any suggestions of how to test the hundreds of operators would be welcomed!

(file #36370, file #36371, file #36372)

Yes, the arguments are being flattened to 2D implicitly, through a maze of macros in libinterp/operators/op-??-??.cc

I'm preparing a patch, but there are lots of functions to fix (all combinations of single/double, real/complex, sparse, diagonal, ..., for half a dozen operators (A*B, A/B,   A*B', A'*B, A\B, A'\B)).

This just came up on the help mailing list. I think the following example presents the issue concisely:

octave:15> ones(2,3)*ones(3,1)
ans =

   3
   3

octave:16> ones(2,3)*ones(3,1,2)
ans =

   3   3
   3   3

octave:17> ones(2,3)*ones(3,1,2,2)
ans =

   3   3   3   3
   3   3   3   3

octave:18> ones(2,3)*ones(3,1,2,2,2)
ans =

   3   3   3   3   3   3   3   3
   3   3   3   3   3   3   3   3

Each of those except the first should produce a non-conformant argument error. (Matlab 2015b errors out in these cases)

The email discussion thought maybe the issue had to do with broadcasting, but it now seems unrelated (and should be, since .* is uninvolved). 

Is mtimes flattening the argument to 2D (from nxm mxpxq to nxm mx(p*q) ) and skipping any conformance checking?

(verified still exists in 4.0.1rc3)