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


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

Submitted by:  John Hunt <huntj>
Submitted on:  Mon Mar 4 21:14:16 2013  
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Sun Nov 20 21:44:45 2016, 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 Oct 9 19:21:04 2015, 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

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 Mar 5 09:03:04 2013, comment #5:

For cases like the original submission, the 'a' size is not
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 Mar 5 02:05:17 2013, 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:

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 Mar 5 00:27:33 2013, comment #3:

My 2 cents, I think of

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

Rik <rik5>
Project Administrator
Mon Mar 4 22:34:35 2013, 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 Mar 4 22:31:32 2013, 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 Mar 4 21:14:16 2013, original submission:

line 3 should broadcast, as on the next line.

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 File(s):

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -unavailable- added by hardy (Posted a comment)
  • -unavailable- added by ederag (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by huntj (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Oct 28 03:53:06 2013mtmillerDependencies-=>bugs #40374 is dependent
    Mon Mar 4 22:31:32 2013jordighStatusNone=>Confirmed

    Back to the top

    Powered by Savane 3.1-cleanup1