Tue 05 Sep 2017 05:02:22 PM UTC, comment #7:
Thanks for testing. I'm switching the Item Group to Regression since this used to produce an error (even if not exactly on topic).
|
Tue 05 Sep 2017 03:55:04 PM UTC, comment #6:
Appears to still be relevant.
Matlab 2017a:
Octave 4.2.1:
|
Sun 03 Sep 2017 12:58:23 AM UTC, comment #5:
Since Matlab has added broadcasting in 2016B, is their behavior still the same as reported in the original submission which was for version 2015B?
I just want to make sure this bug is still relevant.
|
Thu 18 Feb 2016 01:51:45 AM UTC, comment #4:
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)
|
Wed 17 Feb 2016 02:53:04 PM UTC, comment #3:
Yikes. repeated code? or not identical enough for it to be functionalized and addressed in one place?
|
Wed 17 Feb 2016 02:01:35 AM UTC, comment #2:
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 (AB, A/B, AB', A'*B, A\B, A'\B)).
|
Tue 16 Feb 2016 11:13:45 PM UTC, comment #1:
Confirmed. FTR, did produce an error in 3.8.x and earlier, although it was not a non-conformant argument error:
|
Tue 16 Feb 2016 09:19:01 PM UTC, original submission:
This just came up on the help mailing list. I think the following example presents the issue concisely:
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)
|