Re: Ideas for auto BSX

[Jordi Gutiérrez Hermoso]

2011/10/1 Dan Davis <address@hidden>:
> 2011/10/1 Jordi Gutiérrez Hermoso <address@hidden>:
>>On 1 October 2011 05:51, Dr. Alexander Klein <address@hidden> wrote:
>>>
>>> Why not introduce five new two-character infix operators, like for
>>> example $+, $-, $*, $/, $^, or whatever instead of $ fits in the
>>> first position?
>>
>> I would like to avoid introducing more obscure notation. Obscure
>> notation was why I implemented this feature in the first place. Auto
>> BSX is simply that -- more convenient notation.
>>
>> Do you think most users of numpy are horribly confused by what numpy
>> calls broadcasting? Do you think this is a reason to avoid numpy? It
>> seems to work for them and its users seem to love it. Do you think
>> people bring different expectations to Octave and would thus hate BSX?
>>

> I will say that if the behavior of the operators is changed, that
> should be very prominently displayed.  I would actually suggest a big
> message be displayed to the user on Octave startup for a few versions.
>  Something along the lines of,
>
> WARNING: Behavior has changed for the +, -, .*, and ./ operators in
> this version and is no longer MATLAB compatible.  See the
> documentation for details.

I like this idea. It is Matlab-compatible, however, since all Matlab
code that worked before will still work in Octave. It's only code that
didn't work in Matlab will now work in a perhaps unexpected way in
Octave. That is why I decided to implement it, since it's still
backwards compatible with Matlab.

As I've said before, I don't see "Matlab compatibility" to be anything
more than source compatibility. If it runs in Matlab, it should run in
Octave and produce almost the same result (perhaps slight variation in
graphics is acceptable, for example). I don't see making everything in
Octave working and looking exactly like Matlab to be the goal. We
already have lots of other nice Octave-only language features (e.g.
being able to define functions interactively without needing a
separate file for each or being able to index temporaries), and that's
not lack of Matlab compatibility.

By the way, not everyone seems to have realised, but all of the
following tests pass now:

    
http://hg.savannah.gnu.org/hgweb/octave/file/37e6f54cca15/src/DLD-FUNCTIONS/bsxfun.cc#l772

Notice that it's also enabled e.g. for atan2 and mod. Basically, the
bsxfun function is now almost completely redundant for built-in Octave
functions and possibly is only desirable for user-supplied functions.

It's also slightly faster too to do v - v' instead of
bsxfun(@minus, v, v'), due to the function call overhead.

I really want to promote BSX. Repeating myself, it's a powerful
vectorisation technique. I have seen many people looping when BSX
would have been better, and BSX solves some of the most frequent
unnecessary looping . It should thus be natural as it's natural to
users of numpy. We don't have to take all of our inspiration only from
Matlab.

I am writing documentation for all of this in a new chapter for the
Octave manual and I will put many cross references to it in all the
relevant parts of the manual. Yes, I want to make a big deal out of
this; very, very prominently documented.

- Jordi G. H.