Michael, in comment #7, you mentioned
  warning ("error", "Octave:broadcast");

IIRC the old warning ID removed from 4.0.0 was "Octave:automatic-broadcast".

An unfortunate side-effect of Octave allowing user-defined warnings is that no warning is given if a non-existent warning is specified -- I suspect the line you add to you .octaverc doesn't help.

@lachlan

I take back what I said.  This option to move items to another tracker seems duplicates the whole discussion :/  (and on top of that, seems I messed up when selecting the tracker to move this)


Most people will either add a bug or patch report and not think much about it.  Many of them will only do it once and you can't tell them in advance about where they should report it  Telling them to open it again on the other tracker is not very productive.  Since you can't move items between trackers, you will end up with wrong type of reports on each tracker. So having different trackers will actually make things harder to triage since you will have to search on all.

But you're doing a lot of work with the triaging so whatever you feel works best.  I'm happy either way, just let me know.

@Lachlan

> [...] When you distinguish "local" from "the scope of the function", what is the difference? Does "local" mean just the current stack frame and "scope" mean the stack frame and all descendants?

Indeed, local usually means local to the function.  But some years ago, warning has an option named "local" which only affects the current stack frame and downstream.  You are well aware that warning states are global, but if you don't know about the "local" option", see the effect here:

function trigger_warn ()
  5 / 0;
endfunction

function foo ()
  disp ("trigger warning in subfunction");
  trigger_warn ();
  disp ("'locally' disable warning and cause warning in sub-function");
  warning ("off", "Octave:divide-by-zero", "local");
  trigger_warn ();
endfunction

warning ("query", "Octave:divide-by-zero")
foo ()
warning ("query", "Octave:divide-by-zero")

Which generates:

octave> warning ("query", "Octave:divide-by-zero")
ans =

  scalar structure containing the fields:

    identifier = Octave:divide-by-zero
    state = on

octave> foo ()
trigger warning in subfunction
warning: division by zero
warning: called from
    trigger_warn at line 2 column 5
    foo at line 3 column 3
'locally' disable warning and cause warning in sub-function
octave> warning ("query", "Octave:divide-by-zero")
ans =

  scalar structure containing the fields:

    identifier = Octave:divide-by-zero
    state = on

This reduced the use of unwind_protect blocks.  The use of word "local" for this option was unfortunate (there are several other like this, try 'lookfor ("-all", '"local"')').

So when I said 'scope of the caller only (different from the "local" option in warning)', I mean only the current stack frame.

> [...] suggesting "underline /", "underline *" etc for operations with broadcast. Any other combination of symbols would be fine. [...] Was that discussed at OctConf too?

No, only whether we should place the warnings back or remove the language extension warning.

> On an unrelated note, how would you feel about putting these "to-do" items in the task list, instead of the bug list?

I wrote a long text explaining that was not good because you can't move items between trackers.  Seems Like I was wrong.  The only thing I'll point out is that I feel less people subscribed to the task and patch tracker (based on the reduced number of replies I get when I report there).  I'll move this to the task tracker.

On an unrelated note, how would you feel about putting these "to-do" items in the task list, instead of the bug list?

The task list is quite underused, and triage is easier if wishlist items are separated from "it doesn't work" bugs.

> 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.

Broadcasting is useful in cases where dimensions may
validly vary according to some requirements, such as
bus widths for example.

But, its accidental use can be dangerous and confusing.
Thus, the default warning is appropriate.
That is the way I use it.

Just like we support assignment to arrays with a scalar:

a = zeros (3, 4);
a(:,:) = 5;

It would be nice we could also broadcast for assignment, like so:

a = zeros (3, 4);
a(:,:) = [0:3];