octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Auto BSX functionality


From: Rik
Subject: Re: Auto BSX functionality
Date: Sat, 01 Oct 2011 17:30:07 -0700

On 10/01/2011 09:41 AM, 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?
>> >
>> > - Jordi G. H.
>> >
> As a user of Octave, I would prefer keeping the operator behavior as
> is.  bsxfun works fine for me, and I have frequently depended on the
> operators throwing errors when array orientations are mismatched.
> Also, it would be one more place where Octave and Matlab behavior
> would differ.  I'm not a user of numpy, so I can't comment on that
> part, but I would actually prefer a third set of operators for bsx
> operations.  Would that be any more obscure than the existing * and .*
> level of obscurity?  Certainly it would be new, but as people became
> aware of it, the obscurity would fade.  Also, if it's a significant
> enough change, it should be broadly announced.
>
> 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.
10/1/11

I think that Jordi is generally right in this being a good thing;  But, I
do empathize with Dan.  I'm a moderate power user and I've tripped over the
added functionality several times in the last few days.  I've been doing
signal processing where I apply a window function to a sample using ".*". 
In the past, I never bothered to keep the extra bit in my head which
indicated whether a variable name was a row vector or a column vector.  I
think it is analogous to the situation with spelling and spellcheckers.  Do
I really need to devote part of my memory to rules like "I before E except
after C" or can I outsource that to a spellchecker and just type "recieve"
and have it flagged.  I never bothered to remember whether my vectors were
row or column and just let the interpreter tell me when I needed to
transpose one to get things to work.  Maybe I'll adopt a naming convention
such as the suffix 'r' and 'c' to indicate the type of vector I've
created.  I certainly agree that this change needs to be very prominently
displayed to users.  In the mean time, I think I'll go on inadvertently
creating 8192 X 8192 matrices. :)

--Rik


reply via email to

[Prev in Thread] Current Thread [Next in Thread]