Re: Removing broadcasting from Octave

[Jordi Gutiérrez Hermoso]

On 14 December 2011 12:30, Ben Abbott <address@hidden> wrote:
>
> On Dec 14, 2011, at 12:14 PM, John W. Eaton wrote:
>
>> 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.
>
>> | 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.

>
> I see your point.
>
> But then, what is expected for ...
>
>        rand (4,4) * (1:4)
>
>        rand (4,4) .* (1:4)
>
>        rand (4,4) / (1:4)
>
>        rand (4,4) ./ (1:4)
>
> I was thinking that ".<op>" would imply a repmat(), while "op" would
> stick to standard matrix operations.

Right, if we keep broadcasting and decide to distinguish + and .+, I
agree that the latter should broadcast, for consistency with * and .*

Actually, I am very much in favour of this, and I suspect it would fix
a good deal of broken expectations. From the code I've read, most
people do not do .+ except when cargo-culting .* and ./ with the
mistaken belief that "all elementwise operations need a dot in front
of them". Thus, +, -, *, and / would all consistently perform matrix
operations without broadcasting.

- Jordi G. H.