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 04 Mar 2013 09:14:16 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

( Jump to the original submission)

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:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -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)
  •  

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

    Only project members can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-28 mtmiller Dependencies- => bugs #40374 is dependent
    2013-03-04 jordigh StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.5