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

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

[Octave-bug-tracker] [bug #47687] automatic broadcasting for assignment


From: Carnë Draug
Subject: [Octave-bug-tracker] [bug #47687] automatic broadcasting for assignment operations
Date: Thu, 14 Apr 2016 15:42:41 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.7.1

Follow-up Comment #4, bug #47687 (project octave):

> Why would this be nice?
>
> It is easy to use repmat for this situation.

Exactly because it avoids using repmat, and will perform faster.  This is
exactly the same as numpy.

> As I have previously pointed out, automatic broadcasting masks many
programming errors making debugging harder. Remember that the size of a may
have been set in an entirely different function.

Isn't that the beauty of it?  You don't know the size of "a" so you don't have
to worry about expanding "b" yourself.  And while you don't know the size of
"a", you do know what it represents, and what each of its dimensions are.

> If you saw the line
>
> a(:,:) = b;
>
> in isolation, you would have no way of knowing whether or not broadcasting
had been applied, or to what dimension. If you expected b to be a scalar, it
would be nice for the system to warn you that it wasn't -- but we can't
because we can't set warnings for automatic broadcast.

Actually, if "b" is a scalar this is automatic broadcasting.  It is expanding
"b" singleton dimensions as necessary.

> Also notice that in all other cases, automatic broadcasting is symmetric in
the dimensions of the two arguments. Would you expect
>
> a(1, 1:2) = eye (2);
>
> to give you a 1x2 or 2x2 result, or an error?

An error.  Assignment is not a symmetric operation, you can only expand the
RHS.

> In our last discussion, you said that there should be no warning for
automatic broadcasting because "it is part of the language".

It was not that straightforward but yes.  This then got further discussed in
person during OctConf, including placing that warning back.  The argument is
that automatic broadcasting is part of the language and it has an isue with
Matlab incompatibility, therefore it goes in the same warning as all other
language extensions.  But there is a real case to be made about having it as a
separate error to prevent other errors (although maybe that only happened in
the beginning, I haven't seen many error reports about it in a long while).

It has also been discussed elsewhere that the whole language-extensions
warning is useless and I agree (we might as well just get rid of it. Octave is
unusable with that warning enabled).  But that is an issue how warnings work
in the language and it's required for Matlab compatibility.  Say we do make a
separate warning for broadcast.  Normal use of Octave will be throwing
warnings because octave core and packages do make use of broadcast on
purpose.

So unless Octave gets a new way to set warnings within the scope of the caller
only (different from the "local" option in warning), such warning will be of
quite limited use.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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