|
From: | Przemek Klosowski |
Subject: | Re: Removing broadcasting from Octave |
Date: | Wed, 14 Dec 2011 12:18:49 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 |
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'
[Prev in Thread] | Current Thread | [Next in Thread] |