On Wed, Sep 19, 2012 at 3:04 PM, Thomas Weber
<address@hidden> wrote:
On Wed, Sep 19, 2012 at 12:48:42PM -0400, Judd Storrs wrote:
> In my code, using bsxfun allowed me achieve massive performance gains in my
> workload at the price of readability. But now with broadcasting I get the
> performance gains without losing readability--in fact it's even more
> readable than the loop form! Further, this decision wasn't made lightly and
> it was discussed to death. Ultimately, even with broadcasting enabled,
> Octave is fully capable of running valid Matlab code. We've been waiting
> for someone to show *actual* harm from the change.
The example is in the documentation, under "Broadcasting and Legacy
Code". If you have code that relies on catching the mentioned error, you
can either change Octave's default behaviour or you can change your code -
but you cannot run previously working, _unchanged_ code with the
_default_ Octave behaviour.
And actually I don't think Sergei was wading through Octave's source
code to find something to criticise - I bet he has previously working
code that doesn't work anymore.
Well, I will just put this out there, I've floated IDL features before and they're usually ignored or frowned on in the past. But IDL solves this problem very well.
IDL started with some legacy design decisions that were getting in the way. For example, IDL started with () indexing and () function calls. They decided they would prefer the language to migrate to [] for indexing and () for function calls because it would help the VM compiler/optimizer if it could distinguish between function calls from indexing (IDL compiles to an intermediate VM code). There were also additional huge change related to changing the default indexing type from 16bit to 32bit--IDL is more strict on datatypes than Matlab/octave). This of course would break piles of legacy code so it was disabled by default. The way IDL handled this is they introduced a "compile_opt" statement that toggles language features but only within the immediate scope. You could then continue to run unmodified legacy code and enable/disable specific features:
COMPILE_OPT STRICTARR <-- require [] indexing
COMPILE_OPT DEFINT32 <-- use 32bit indexing
COMPILE_OPT HIDDEN <-- "hide" the function from the help command
COMPILE_OPT OBSOLETE <-- calling this function generates a warning
COMPILE_OPT IDL2 <-- recommended, alias for COMPILE_OPT DEFINT32, STRICTARR
Setting a COMPILE_OPT only affects the current scope--it doesn't affect the scope that called or any of the scopes that it calls, etc. The brilliance of this is that you can easily mix and mash code that conforms to old or new and not worry about new language features breaking legacy libraries.
It does actually make me quite uneasy to have to disable the octave:broadcast warning *globally* affecting code that I have not examined (and that I doubt anyone has examined--on the other hand that's what the unit tests are for... at least in the core). If I could just mark octave:broadcast as a default to error but then allow it in individual functions (or even for all functions in a directory), I would be extremely happy. For a lot people, it could make life easier if Octave defaulted to strict Matlab compatibility with an easy way to toggle on octave enhancements on a file-by-file basis.
--judd