From: Daniel Armyr on
Hi.
This is an idea I am throwing out to see what happens.

I propose that matlab introduce a quick-notation form for bsxfun. I propose that this notation would follow in the footsteps of the .* notation (.* ./ .^) in that it uses two letters where the first one is an indicator that something unusual is going on, in this case that bsxfun is being used, and the second one says which operator is being used.

The pros of this notation is that one could easilly and quickly create multi-dimensional matrices from formulas with multiple inputs without having to go through the meshgrid and the likes.

Further, it would simplify the writing of more complicated formulas using the bsxfun idea of matrix mathematics. bsxfun cannot handle more than 2 arguments, and complex formulas require the writing of a function.

Finally, the current bsxfun notation is somewhat of a hurdle to get over. It looks scary to all but the most seasoned matlab speakers.

Two cons immediately come to mind. The first being that enlargening the language makes reading code more complex. Well, TMW is constantly expanding the language, so what are ten more commands?

The second is that the notation may be seen as confusing. However, as there already exists a precedent (.*-notation), matlab users should be equiped to grasp the new notation quickly.

Sincerely
Daniel Armyr
From: Bruno Luong on
Here is the my FEX submission that allows to do exactly that:
http://www.mathworks.com/matlabcentral/fileexchange/23821-bsxops

The inconvenient is the overhead will slow down operations on small vectors/scalars. Mathworks could in-fact integrated such syntax with built-in library.

>> a=reshape(1:2,[],1,1);
>> b=reshape(1:3,1,[],1);
>> c=reshape(1:4,1,1,[]);
>> bsxops(1)
>> a+b+c

ans(:,:,1) =

3 4 5
4 5 6


ans(:,:,2) =

4 5 6
5 6 7


ans(:,:,3) =

5 6 7
6 7 8


ans(:,:,4) =

6 7 8
7 8 9

>> (a+b).*c

ans(:,:,1) =

2 3 4
3 4 5


ans(:,:,2) =

4 6 8
6 8 10


ans(:,:,3) =

6 9 12
9 12 15


ans(:,:,4) =

8 12 16
12 16 20

>> bsxops(0)
>> a+b+c
??? Error using ==> plus
Matrix dimensions must agree.

% Bruno
From: Daniel Armyr on
Interesting. At least I am not the only one to think along these lines.

In addition to your overhead, i see one more drawback of having a mode that is activated and deactivated and that is that you cannot mix bsxfun math and normal math in a single formula.
From: John D'Errico on
"Daniel Armyr" <firstname(a)lastname.se> wrote in message <hs1a39$2d4$1(a)fred.mathworks.com>...
> Hi.
> This is an idea I am throwing out to see what happens.
>
> I propose that matlab introduce a quick-notation form for bsxfun. I propose that this notation would follow in the footsteps of the .* notation (.* ./ .^) in that it uses two letters where the first one is an indicator that something unusual is going on, in this case that bsxfun is being used, and the second one says which operator is being used.
>
> The pros of this notation is that one could easilly and quickly create multi-dimensional matrices from formulas with multiple inputs without having to go through the meshgrid and the likes.
>
> Further, it would simplify the writing of more complicated formulas using the bsxfun idea of matrix mathematics. bsxfun cannot handle more than 2 arguments, and complex formulas require the writing of a function.
>
> Finally, the current bsxfun notation is somewhat of a hurdle to get over. It looks scary to all but the most seasoned matlab speakers.
>
> Two cons immediately come to mind. The first being that enlargening the language makes reading code more complex. Well, TMW is constantly expanding the language, so what are ten more commands?
>
> The second is that the notation may be seen as confusing. However, as there already exists a precedent (.*-notation), matlab users should be equiped to grasp the new notation quickly.
>
> Sincerely
> Daniel Armyr

There was a team that considered doing something like this
before bsxfun was released. The problem is multi-fold as I
see it.

By defining an entire new family of operators, it makes matlab
yet more complex to learn. As it is, see how many errors we
see when people fail to understand the difference between
* and .*, / and ./, ^ and .^, etc.

Adding a new family of operators also makes matlab less
compatible to old versions. The existence of bsxfun will
break code from a new release of matlab when you try to
run it in an old release. HOWEVER, that is trivially fixed if
you wish to do so. All you need to do is to implement a
function in your old matlab release called bsxfun, written
using matlab and reshape. Yes, it will not be as efficient
as bsxfun, but it will now be perfectly compatible. This
fix is a simple one.

Consider what happens if they were to introduce a new
family of operators? It is impossible to implement in an
old matlab release, to make it compatible. You cannot
define a new operator that the parser will understand.
Only TMW can do so.

Finally, creating an entire new family of operators makes
matlab itself considerably more expensive to maintain in
as bug-free a form as they want it to be. The parser must
be modified. Acceleration problems. Bugs repaired and
tracked. Ugh.

The bsxfun tool offers a large gain for relatively little cost.
But a new family of operators? Nope. The end result is
that your suggestion is simply not worth the costs.

John
From: Bruno Luong on
"Daniel Armyr" <firstname(a)lastname.se> wrote in message <hs1cih$g0m$1(a)fred.mathworks.com>...
> Interesting. At least I am not the only one to think along these lines.
>
> In addition to your overhead, i see one more drawback of having a mode that is activated and deactivated and that is that you cannot mix bsxfun math and normal math in a single formula.

You don't have to activate/disactivate BSXOPS, you can let it activate constantly. I just add the disactivate option in order to ensure the compatibility and avoid overhead in "normal" operation.

Bruno