Thread Subject: matrix vector indexing

I have a node connectivity matrix such as:
t =[ 1 2 4
     2 3 5
     4 5 7
     5 6 8
     5 4 2
     6 5 3
     8 7 5
     9 8 6];
for each node of the connectivity I have a value such as:
mae =[0.6787 0.2769 0.4387
    0.7577 0.0462 0.3816
    0.7431 0.0971 0.7655
    0.3922 0.8235 0.7952
    0.6555 0.6948 0.1869
    0.1712 0.3171 0.4898
    0.7060 0.9502 0.4456
    0.0318 0.0344 0.6463];
I want to store each value of array 'mae' into a vector of size (in this example) 9.
I need to do this millions of times and the size of the arrays is very large. I find this loop, which I am currently using, very slow:
x = zeros(Np,1);
for i=1:size(t,1)
    x(t(i,1)) = x(t(i,1)) + mae(i,1);
    x(t(i,2)) = x(t(i,2)) + mae(i,2);
    x(t(i,3)) = x(t(i,3)) + mae(i,3);
end
does anyone know a faster way to do this, perhaps avoiding the loop?
thanks for your help

Luca

trave Traverso wrote:
...
> x = zeros(Np,1);
> for i=1:size(t,1)
> x(t(i,1)) = x(t(i,1)) + mae(i,1);
> x(t(i,2)) = x(t(i,2)) + mae(i,2);
> x(t(i,3)) = x(t(i,3)) + mae(i,3);
> end
> does anyone know a faster way to do this, perhaps avoiding the loop?

Isn't this just

x(t) = x(t) + mae(t);

?

--

dpb wrote:
> trave Traverso wrote:
> ...
>> x = zeros(Np,1);
>> for i=1:size(t,1)
>> x(t(i,1)) = x(t(i,1)) + mae(i,1);
>> x(t(i,2)) = x(t(i,2)) + mae(i,2);
>> x(t(i,3)) = x(t(i,3)) + mae(i,3);
>> end
>> does anyone know a faster way to do this, perhaps avoiding the loop?
>
> Isn't this just
>
> x(t) = x(t) + mae(t);
>
> ?

I came back to fix what I thought was a typo but realized I misread your
indices so no, it isn't. :(

OTOMH I don't see a clever solution, unfortunately.

--

x = accumarray(t(:), mae(:), [Np 1], @sum)

% Bruno

Bruno Luong wrote:
> x = accumarray(t(:), mae(:), [Np 1], @sum)

Yeah, there's an advantage of later releases than I have; accumarray()
postdates my version.

There's a typo in his example I think, at least as he wrote the loop x
should be [Np,3] instead of [Np,1]. Will the above work as expected then?

--

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hag25m$opd$1@fred.mathworks.com>...
> x = accumarray(t(:), mae(:), [Np 1], @sum)
>
> % Bruno

Bruno,

Why not just

x2 = accumarray(t(:), mae(:), [Np 1])

or if Np == max(t(:))

x2 = accumarray(t(:), mae(:))

I think this will be faster than calling accumarray with a function handle that does what accumarray does anyway.

dpb <none@non.net> wrote in message <hag349$47h$3@news.eternal-september.org>...

>
> Yeah, there's an advantage of later releases than I have; accumarray()
> postdates my version.

That's pitty. ACCUMARRAY is powerful and fast. It 's one of the most fundamental command for vectorizing codes. I can't survive with it. ;-)

>
> There's a typo in his example I think, at least as he wrote the loop x
> should be [Np,3] instead of [Np,1]. Will the above work as expected then?

Don't see anything incoherent about [Np,1]. But OP will confirm.

Bruno

"Matt Fig" <spamanon@yahoo.com> wrote in message <hag380$4ri$1@fred.mathworks.com>...

> I think this will be faster than calling accumarray with a function handle that does what accumarray does anyway.

You are right for the note on @sum Matt. I believe (?) specifying the size always leads to faster.

Bruno

Bruno Luong wrote:
> dpb <none@non.net> wrote in message <hag349$47h$3@news.eternal-september.org>...
>
>> Yeah, there's an advantage of later releases than I have; accumarray()
>> postdates my version.
>
> That's pitty. ACCUMARRAY is powerful and fast. It 's one of the
> most fundamental command for vectorizing codes. I can't survive with
> it. ;-) >

Yeah, if weren't essentially retired from consulting (at least I think 5
years since did any _should_ qualify :) ) I can't justify $$ and haven't
tried to see if the work done w/ local c-college would qualify enough
for a student license so I putter along making do... :)

>> There's a typo in his example I think, at least as he wrote the loop x
>> should be [Np,3] instead of [Np,1]. Will the above work as expected then?
>
> Don't see anything incoherent about [Np,1]. But OP will confirm.

It isn't except he does a loop on I w/ separate lines inside on 2nd
array indices of 1, 2, 3. W/ x(Np,1) there's an out-of-bounds condition
and if it doesn't error it's reallocating every pass. If it's really as
the example, that could be a major part of his speed problem (not that
using accumarray() isn't better)...

--

dpb <none@non.net> wrote in message <hagasn$gpi$1@news.eternal-september.org>...
> Bruno Luong wrote:
> > dpb <none@non.net> wrote in message <hag349$47h$3@news.eternal-september.org>...
> >
> >> Yeah, there's an advantage of later releases than I have; accumarray()
> >> postdates my version.
> >
> > That's pitty. ACCUMARRAY is powerful and fast. It 's one of the
> > most fundamental command for vectorizing codes. I can't survive with
> > it. ;-) >
>
> Yeah, if weren't essentially retired from consulting (at least I think 5
> years since did any _should_ qualify :) ) I can't justify $$ and haven't
> tried to see if the work done w/ local c-college would qualify enough
> for a student license so I putter along making do... :)
>
> >> There's a typo in his example I think, at least as he wrote the loop x
> >> should be [Np,3] instead of [Np,1]. Will the above work as expected then?
> >
> > Don't see anything incoherent about [Np,1]. But OP will confirm.
>
> It isn't except he does a loop on I w/ separate lines inside on 2nd
> array indices of 1, 2, 3. W/ x(Np,1) there's an out-of-bounds condition
> and if it doesn't error it's reallocating every pass. If it's really as
> the example, that could be a major part of his speed problem (not that
> using accumarray() isn't better)...
>
> --
Hi all,
thanks a lot for your help. The accumarray suggestion is what I was looking for.
No there is no typo, [Np 1] is ok as I need a vector (and I forgot to mention Np = max(t)).
thanks again for the help.

Luca
 

trave Traverso wrote:
...

> No there is no typo, [Np 1] is ok as I need a vector ...

OK, my bad...I went back and looked and see I did misread that as
well--the addressing is linear 1D, indeed.

--