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.)
|
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) ?
|
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.
|
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:
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.
|
Tue 05 Mar 2013 12:27:33 AM UTC, comment #3:
My 2 cents, I think of
as an in-place operation which doesn't affect size of a.
|
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?
|
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.
|
Mon 04 Mar 2013 09:14:16 PM UTC, original submission:
line 3 should broadcast, as on the next line.
hg id -in
8366bc871d45 16188
It might be related to bug #35787
|