Re: accumarray

etienne <at> isr.ist.utl.pt wrote:
>   Hi David,
>
> On Thu, July 5, 2007 02:57, David Bateman wrote:
> # etienne <at> isr.ist.utl.pt wrote:
> #>   I would say that correct but slow code is better than no code at all.
> #>
> #>   Cheers,
> #>
> #>   Etienne
> #>
> #>
> # Well, I'm back in the office and tried the accumarray in matlab for
> # speed and got the following results
> #
> # vals = 1:1e4;
> # subs = randint(1e4,2,1024) + 1;
> # t = 0;
> # for i=1:10,
> #   t0 = cputime();
> #   A = accumarray (subs, vals, [1024,1024]);
> #   t = t + cputime() - t0;
> # end;
> # fprintf('Time %g s\n', t / 10);
> #
> # MatlabR2007a
> # Time 0.016 s
> #
> # Octave 2.9.12
> # Time 1.21592 s
> #
> # So there is a factor of 76 difference in speed for this example. So
> # Etienne how useful is this function, and what portion of your simulation
> # time will be spent in it?
>
> I usually am first happy when code work correctly; if it is fast too, that's
> better, but I place correctness first. I am sure that people who have M* code
> w/ accumarray() in it will rather be able to run their code than not.
>
>   
In any case I found a further speed important in the m-file, and have
Octave now giving.

Time 0.765784 s

so the speed difference for this case is now a factor of 48.... I agree
that correctness is more important than speed, and in fact speed is
irrelevant is bits of code that you don't spend much time in anyway.. So
I believe that the code is probably fine.. John want me to commit it?

regards
David

--

-- 
David Bateman                                David.Bateman <at> motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary