Re: Removing broadcasting from Octave

[Przemek Klosowski]

On 12/14/2011 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.

I am torn---it looks like a nice and expressive feature that would make 
Octave even more convenient for rapid code development; at the same 
time, it's easy to make a hard-to-see mistake, and it hampers 
compatibility with Matlab.

On the other hand, you don't have to use it, so if compatibility or 
safety is a consideration, you could always chose to use bsxfun() 
explicitly. This leaves the case of hidden errors, so my question is 
could something be done to help diagnosing the data flow in the new 
expressions---perhaps toggable warning saying 'auto-bsxfun operation on 
an NxM vs KxL array resulting in a PxQ array'