Re: Removing broadcasting from Octave

[John W. Eaton]

On 14-Dec-2011, Ben Abbott wrote:

| On Dec 14, 2011, at 11:31 AM, Jordi Gutiérrez Hermoso wrote:
| 
| > I think the whole thing may simply be a bad idea.
| > 
| > The whole point was to do broadcasting as naturally and as frequently
| > as Numpy does. However, we have to write code that works in Matlab,
| > even if it's written for Octave. Plus we have the cultural baggage
| > that this is not how Matlab works, therefore Octave should not work
| > this way either.
| > 
| > I can just back out all the csets that enabled this. There's no point
| > in introducing new syntax for this. We already have syntax, and the
| > obscurity of some operator like x $./ y vs bsxfun(@rdivide, x, y) is
| > not advantageous; they're both equally obscure, and the whole point
| > was to make this natural and frequent by using common syntax.
| > 
| > I imagine there is more support for removing this feature than to keep it.
| > 
| > - Jordi G. H.
| 
| Until you brought "broadcasting" to my attention on this list, I had not 
encountered it before.
| 
| My first impression was that it would be confusing, but after more thought I 
decided it was a more consistent, and I like the idea of now worrying about 
including calls to repmat()
| 
| The only part I'm a bit concerned about is that each of the below behave the 
same.
| 
|       rand (4, 4) + (1:4)
| 
|       rand (4, 4) .+ (1:4)
| 
| Should the first throw an error?

I would think that the second would be the one that would throw the
error, since the dimensions do not agree as they should for
element-by-element operations.

jwe