I applied the first of Lachlan's patches here http://hg.savannah.gnu.org/hgweb/octave/rev/a1aa52bff079.  This fixes the error originally seen with bsxfun.  There is still a problem with the operator '+' when it needs to do automatic broadcasting.

t1 = randn(6,3)+1j*randn(6,3);
t2 = randn(6,1);
s1 = sparse(t1);
s2 = sparse(t2);

bsxfun (@plus, s1, s2)  # This works NOW
s1 + s2
error: operator +: nonconformant arguments (op1 is 6x3, op2 is 6x1)

The second patch from Lachlan no longer applies cleanly.  I can look at it again when it is refreshed to current tip.

Hi Thanks,

Please be patient, devs do care for patches but the manpower available is not a lot. If you think your patch has been sitting here for too long, just ping it and send an email to the mailing list. It probably it is just that dev haven0t seen it.

This report actually describes something unrelated to the problems with automatic broadcasting of sparse matrices.  The bug with the explicit use of bsxfun is that the variable  C  in bsxfun() is not initialised properly for sparse matrices.  It is fixed by the attached patch.  It affects broadcast between any two sparse matrices of different storage types, such as single/double.


There is also a more subtle bug in bsxfun (f, a, b) when
f (a(:,1), b(:,1))  has a different type from  f (a(:,2), b(:,2)).
The slow-path code converts singles to doubles, instead of doubles to
singles.  To see this, try

octave> a = [1, 2; 1, 2]; b = [1, 1];
octave> C = { single(1) , 2 };
octave> f = @(a,b) ([C{a}]');
octave> t = bsxfun (f, a, b);
octave> tt = [f(a(1,1),b(1,1)), f(a(1,2),b(1,2))
              f(a(2,1),b(1,1)), f(a(2,2),b(1,2))]
octave> whos
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        C           1x2                         12  cell
        a           2x2                         32  double
        b           1x2                         16  double
        f           1x1                          0  function_handle
        t           2x2                         32  double
        tt          2x2                         16  single

Total is 17 elements using 108 bytes

This is not too serious; Matlab gives an error if the output of  f  has a different storage type, except for promoting real to complex.  I'd be happy to fix this if it would be committed, but most of the patches I have submitted recently haven't been reviewed yet, so I'm not sure if it is worth it.

FWIW, the code in bsxfun() is pretty hard to follow, so I've written a bit of documentation, in the second attached patch.

(file #34976, file #34977)

Thanks for the report. This is mostly the same as previously reported bug #41441, can you add the specific details about complex types to that report?

Sorry, markup typo cut off the report. Here it is again.

t1 = randn(6,3)+1j*randn(6,3);
t2 = randn(6,1);
s1 = sparse(t1);
s2 = sparse(t2);

These work fine:

t1 + t2
bsxfun( @plus, t1, t2 )

These fail, each in different ways, but they should produce the same results as above, only sparse:

>> s1 + s2
error: operator +: nonconformant arguments (op1 is 6x3, op2 is 6x1)
>> bsxfun(@plus,s1,s2)
error: concatenation operator not implemented for '<unknown type>' by 'sparse complex matrix' operations

Matlab does the correct thing with the bsxfun functions, but of course it does not consider the bare additions to be correct.