octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #45219] Incorrect behavior with broadcasting a


From: Lachlan Andrew
Subject: [Octave-bug-tracker] [bug #45219] Incorrect behavior with broadcasting and mixed real/complex matrices
Date: Fri, 25 Sep 2015 06:53:11 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Follow-up Comment #5, bug #45219 (project octave):

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)
    _______________________________________________________

Additional Item Attachment:

File name: bug_45219.patch                Size:0 KB
File name: bsxfun_cc_comments.patch       Size:8 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45219>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]