Re: Octave and cargo cult programmingHello

[Sergei Steshenko]

>________________________________
> From: Judd Storrs <address@hidden>
>To: Sergei Steshenko <address@hidden> 
>Cc: Michael Goffioul <address@hidden>; "address@hidden" <address@hidden> 
>Sent: Wednesday, September 19, 2012 7:48 PM
>Subject: Re: Octave and cargo cult programmingHello
> 
>
>On Wed, Sep 19, 2012 at 11:47 AM, Sergei Steshenko <address@hidden> wrote:
>
>Sergei is rather expressing frustration with Octave's development going in 
>_strategically_ wrong direction; broadcasting and its stupid (without line 
>number) warning messages being a clear indication of that direction.
>
>
>From a purely *strategic* POV, broadcasting is the right decision given the 
>vast performance difference between vector and loop operations in octave (new 
>JIT branch notwithstanding). IMHO if you want to persuade anyone that 
>broadcasting is a strategic blunder you're going to have to be *specific*. 
>Lacking specificity, it's impossible to discern this from a run-of-the-mill 
>concern troll.
>
>
>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.
>
>
>Further, broadcasting is a well-established and ancient vector-language 
>concept used other high-performance high-level languages like APL and IDL*. 
>IMHO Matlab has been on the wrong side of broadcasting for eons and it's 
>inexcusable that they didn't include it in their language design from the get 
>go. It's probably related to the fact that Matlab started as a linear system 
>solver and didn't get around to dealing with image processing problems or 
>statistics until they had inertia and their communities didn't demand it. IDL 
>on the other hand developed under heavy use by image processing folks which is 
>why you see IDL heavily used historically in the astronomy, remote sensing, 
>and medical imaging communities. 
>
>
>
>
>--judd
>
>
>*In IDL it was slightly different and called "recycling". IDL's approach 
>differs in a few subtle details that aren't worth emulating. Comparatively 
>IDL's implementation can induce some excessive operations (unneeded flipping, 
>transposing, reshaping, permutations). IDL's model does allow mismatched 
>things to be combined (i.e. something like ones(3,5) + ones(2,1) works), which 
>is very, very occasionally legitimately useful but overwhelmingly usually a 
>bug. In any case, the IDL folks have embraced the numpy model which is what 
>octave implemented IIRC. So octave has incorporated the best-of-breed model.



I don't give a damn about broadcasting specifically, but it is a practical 
nuisance for me. To me introduction of broadcasting the way it was done shows 
_strategic_ deficiencies of Octave infrastructure.


In an earlier Email I showed how things are done in Perl - if _desired_, a 
proper module is loaded, and operators are overloaded. And it's the way in 
other normal languages with operator overloading.


Furthermore, introduction of broadcasting exposed me to warnings not containing 
line numbers (while octave error message do contain line numbers - which is 
good).

Warnings without line numbers either demonstrate yet another strategic 
deficiency in Octave infrastructure (in Perl, for example, warnings come with 
line numbers) or, if the infrastructure is in place, complete cluelessness of 
the coder(s) who implemented the (broadcasting) code.


Regards,
  Sergei.












>
>