bugGNU Octave - Bugs: bug #38466, incorrect broadcasting for 'a .*=...

 
 

bug #38466: incorrect broadcasting for 'a .*= b' when b has fewer dimensions than a

Submitter:  John Hunt <huntj>
Submitted:  Mon 04 Mar 2013 09:14:16 PM UTC
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Sat 23 Apr 2022 02:59:43 PM UTC, comment #27: 

Seems to be working now.

Closing as fixed.

Markus Mützel <mmuetzel>
Project Member
Fri 08 Apr 2022 06:59:57 PM UTC, comment #26: 

Passes all tests for me with CLI and GUI with GCC and Clang. Looks more stable certainly.

Arun Giridhar <arungiridhar>
Project Member
Fri 08 Apr 2022 06:21:08 PM UTC, comment #25: 

"Oops. I crossed with jwe's message."

No problem, I wasn't completely sure about the logic there anyway and your change is fine as long as the result is the same.

John W. Eaton <jwe>
Project Administrator
Fri 08 Apr 2022 06:11:56 PM UTC, comment #24: 

Oops. I crossed with jwe's message.

I pushed a change to stable here that should be fixing this:
https://hg.savannah.gnu.org/hgweb/octave/rev/84fa12727b43

It is essentially the same as the change jwe proposed. But I believe, we don't need to get the `min` because we return early on `(r_nd < x_nd)` a few lines before.

Marking as ready for test (again).

Markus Mützel <mmuetzel>
Project Member
Fri 08 Apr 2022 06:04:12 PM UTC, comment #23: 

I haven't done much testing, but maybe the attached change is the right fix?  The same logic is applied in the is_valid_bsxfun function to handle the case when the number of dimensions of the operands don't match, so extra dimensions are always 1.

Note that there are different code paths in product_eq in Marray.cc if the LHS is shared.  So maybe that is why calling disp changes the result?

It's also possible we could just see random behavior here or crashes because of accessing dimension elements beyond the size of the allocated dimension array.

(file #53056)

John W. Eaton <jwe>
Project Administrator
Fri 08 Apr 2022 05:31:10 PM UTC, comment #22: 

This is the Octave equivalent of "OpenOffice.org will not print on Tuesdays" (https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28).

For what it's worth, I get the error in both GUI and CLI, but adding disp statements makes it work properly in both. Also, recompiling with optimization set to "-O0" does not make a difference. It's the same behavior with "-O3" and "-O0" for both CLI and GUI. Using gcc 11.2.0 and clang 13.0.1.

Arun Giridhar <arungiridhar>
Project Member
Fri 08 Apr 2022 05:27:10 PM UTC, comment #21: 

$ dpkg -s libreadline8
Package: libreadline8
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 457
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Multi-Arch: same
Source: readline
Version: 8.1-2
Depends: readline-common, libc6 (>= 2.33), libtinfo6 (>= 6)
Description: GNU readline and history libraries, run-time libraries
 The GNU readline library aids in the consistency of user interface
 across discrete programs that need to provide a command line
 interface.
 .
 The GNU history library provides a consistent user interface for
 recalling lines of previously typed input.
Original-Maintainer: Matthias Klose <doko@debian.org>

Markus Mützel <mmuetzel>
Project Member
Fri 08 Apr 2022 05:21:47 PM UTC, comment #20: 

readline issue? (8.1 on Fedora)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 08 Apr 2022 05:16:15 PM UTC, comment #19: 

I did all my previous testing in the GUI. If I do the same on the CLI, it is failing here, too.

The same on Linux and Windows.

The strange thing is that the test suite (`make check`) passes here. (Even though it isn't executed in the GUI.)

(Re-building didn't make a difference. The tests still pass in the GUI.)

I removed the asterisk from the tag with the bug number to pacify the test suite here:
https://hg.savannah.gnu.org/hgweb/octave/rev/b86b86ad4b23

Markus Mützel <mmuetzel>
Project Member
Fri 08 Apr 2022 04:52:52 PM UTC, comment #18: 

For me:

$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)

There are a few configure flags containing "libstdcxx". But tbh, I don't know what they mean or whether they could have any effect here...

Markus Mützel <mmuetzel>
Project Member
Fri 08 Apr 2022 04:47:23 PM UTC, comment #17: 

At the moment on fedora's buildbot computer:

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-11.2.1-20220127/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20220127 (Red Hat 11.2.1-9) (GCC)

Also note that clang's buildbot is failing too.

$ clang -v
clang version 13.0.0 (Fedora 13.0.0-3.fc35)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/11
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/11
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

They share libstdc++

Dmitri.
--

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 08 Apr 2022 04:39:16 PM UTC, comment #16: 

Hu?
That also failed on the buildbots. But it works for me on Ubuntu 21.10 (and on Windows). I can't get it to fail no matter how hard I try. No `disp` or omitting `disp` makes it fail for me.

Maybe compiler version specific?
Here:

$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Template magic that is interpreted differently in different versions?

Or the standard libraries?

I'll check out again and try from a clean start.

Markus Mützel <mmuetzel>
Project Member
Fri 08 Apr 2022 04:25:27 PM UTC, comment #15: 

This looks like a bad heisenbug. On Octave 8 (hg id ec5b57af230a) on Linux, I get this error:

octave:1> clear all; a = ones(2, 2, 2); b = ones(2, 1); c = a .* b; assert (all(a(:) == c(:))); a .*= b; assert (all(a(:) == c(:)))
error: .*=: nonconformant arguments (op1 is 2x2x2, op2 is 2x1)
octave:2>

I then added disp statements to confirm that the first operation was succeeding, and the problem disappeared!

octave:2> clear all; a = ones(2, 2, 2); b = ones(2, 1); disp('First'); c = a .* b; assert (all(a(:) == c(:))); disp('Second'); a .*= b; assert (all(a(:) == c(:))); disp('Third')
First
Second
Third
octave:3>

The same behavior happens if I mix and match the two statements in any order, and is repeatable. The presence of the disp statements causes it to work properly, and if not it causes an error. The first and third disp statements can be removed but the second seems to be required.

Arun Giridhar <arungiridhar>
Project Member
Fri 08 Apr 2022 04:03:18 PM UTC, comment #14: 

Works for me with Octave 7.1.0 on Ubuntu 21.10 and Windows 11.
It looks like this has been fixed by some change in the past.

I added some BISTs here so this doesn't break again accidentally:
https://hg.savannah.gnu.org/hgweb/octave/rev/a4ed2fed7dfa

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Fri 08 Apr 2022 10:12:26 AM UTC, comment #13: 

This is platform specific, works on mac and windows but not Linux.

Anonymous
Tue 30 Nov 2021 10:07:43 PM UTC, comment #12: 

This isn't platform specific so I changed the OS to "Any".

Rik <rik5>
Project Administrator
Tue 30 Nov 2021 08:19:59 PM UTC, comment #11: 

on windows, so  like comment #8 also not seeing the error in Octave 6.4.0. I don't see anything in the comments, why this is a platform specific error?

Nicholas Jankowski <nrjank>
Project Member
Mon 03 May 2021 10:40:35 AM UTC, comment #10: 

Oops this bug is for Linux only.
My results were using mac.

Anonymous
Mon 03 May 2021 01:58:32 AM UTC, comment #9: 

Still the same for me with Octave 6.2 (tested May 2nd, 2021).

octave:7> a = ones (2,2,2);
octave:8> b = ones (2,1);
octave:9> a .*= b
error: .*=: nonconformant arguments (op1 is 2x2x2, op2 is 2x1)

Rik <rik5>
Project Administrator
Fri 30 Apr 2021 11:03:10 PM UTC, comment #8: 

version 6.1.0

a = ones(2, 2, 2);
b = ones(2, 1);
a .*= b
a =

ans(:,:,1) =

   1   1
   1   1

ans(:,:,2) =

   1   1
   1   1

a = a .* b
a =

ans(:,:,1) =

   1   1
   1   1

ans(:,:,2) =

   1   1
   1   1

No errors or warnings.

Anonymous
Sun 20 Nov 2016 09:44:45 PM UTC, comment #7: 

This behavior is still present in Octave 4.2.0.

(Maybe further actions can be more easily decided after bug #35400 is solved.)

Hartmut <hardy>
Fri 09 Oct 2015 07:21:04 PM UTC, comment #6: 

In 4.0.0 also the problem is still there:

a = ones(2, 2, 2);
b = ones(2, 1); # compatible with a, and smaller
a .*= b
yields an error

while
a = a .* b
runs fine

If a .*= b were just syntactic sugar for a = a .* b,
than there should not be any error, right ?

Please note that in this example a is larger than b.
in this case the operation could be done in-place, for better performance. The size of a is not changed at all.

Of course, for b .*= a (where b is smaller than a .* b), the operation could not be done in-place. In this case, b should just receive a .* b.

As a side note
a(:, :, :) .*= b
works, but I suspect there are no optimizations in this case (with respect to a = a .* b) ?

ederag <ederag>
Tue 05 Mar 2013 09:03:04 AM UTC, comment #5: 

For cases like the original submission, the 'a' size is not
changed.
The operation could efficiently be done "in-place".
Am I missing something ?

This kind of optimization can make a lot of difference for memory hungry calculations. IMHO, I would favor it. But I understand why there is debate.

John Hunt <huntj>
Tue 05 Mar 2013 02:05:17 AM UTC, comment #4: 

In Octave, all "A op= B" operators are just syntactic sugar for "A = A op B", so some can change the size of A:

octave:1> A = [1,2,3;4,5,6];
octave:2> B = [1,2;3,4;5,6];
octave:3> A *= B
A =

   22   28
   49   64

That's the expected result and makes sense given the simple rule that A op= B is exactly the same as A = A op B.

John W. Eaton <jwe>
Project Administrator
Tue 05 Mar 2013 12:27:33 AM UTC, comment #3: 

My 2 cents, I think of

a *= b

as an in-place operation which doesn't affect size of a.

Rik <rik5>
Project Administrator
Mon 04 Mar 2013 10:34:35 PM UTC, comment #2: 

Actually, wait. I remember now. I deliberately did it this way, thinking that a .*= b shouldn't change a's size, thinking that broadcasting this way should work in-place without allocating temporaries or more memory. In particular, since it must be in-place, it can't change size(a).

But jwe thinks that a .*= b should be syntactic sugar for a = a .* b and shouldn't attempt to do any sort of tricks like this. At the moment, there is some code, not a lot, that actually attempts to be more efficient with the a OP= b operations than a = a OP b. What do you think should happen?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Mon 04 Mar 2013 10:31:32 PM UTC, comment #1: 

Thanks, confirmed.

bug #35787 is unrelated. That one is about diagonal matrices. This one should be easier to fix.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Mon 04 Mar 2013 09:14:16 PM UTC, original submission:  

line 3 should broadcast, as on the next line.

octave:1> a = ones(2, 2, 2);
octave:2> b = ones(2, 1);
octave:3> a .*= b
error: .*=: nonconformant arguments (op1 is 2x2x2, op2 is 2x1)
octave:3> a = a .* b
warning: product: automatic broadcasting operation applied
a =

ans(:,:,1) =

   1   1
   1   1

ans(:,:,2) =

   1   1
   1   1

hg id -in
8366bc871d45 16188

It might be related to bug #35787

John Hunt <huntj>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53056:  inplace-bsxfun-diff.txt added by jwe (399B - text/plain)

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by ederag (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by huntj (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-02 mmuetzel Dependencies- bugs #62390 is dependent
    2022-04-23 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2022-04-08 mmuetzel StatusConfirmed Ready For Test
    2022-04-08 jwe Attached File- Added inplace-bsxfun-diff.txt, #53056
    2022-04-08 mmuetzel StatusReady For Test Confirmed
    2022-04-08 mmuetzel StatusConfirmed Ready For Test
    2021-11-30 rik5 Operating SystemGNU/Linux Any
    2013-10-28 mtmiller Dependencies- bugs #40374 is dependent
    2013-03-04 jordigh StatusNone Confirmed

    Back to the top


    Powered by Savane 3.9