speed up normpdf

[Hugh]

Hi there,

I am running a bayesian filter which involves thousands of calls to nompdf

curently it is run as follows

for j=1:N

for i=1:N

Con_Prob_VolRtn(i,j)=normpdf((Log_Vol(j)-Log_Vol(i)),-0.5*(nu_sqrt_dt)^2,nu_sqrt_dt);

end
end

It is likely that vectorising the code would speed it up significantly?

Is there a speedier alternative to normpdf?

I tried the lightspeed package but I found normpdf to be better than their version.

[Steven_Lord]

"Hugh " <h_a_pa...@hotmail.com> wrote in message
news:iv450q$q4s$1...@newscl01ah.mathworks.com...

> Hi there,
>
> I am running a bayesian filter which involves thousands of calls to nompdf
>
> curently it is run as follows
>
> for j=1:N
>
> for i=1:N
>
> Con_Prob_VolRtn(i,j)=normpdf((Log_Vol(j)-Log_Vol(i)),-0.5*(nu_sqrt_dt)^2,nu_sqrt_dt);
> end
> end
>
> It is likely that vectorising the code would speed it up significantly?

If you've got the memory, creating the matrix of Log_Vol(j)-Log_Vol(i) and
calling NORMPDF once on that matrix may be faster, yes.

> Is there a speedier alternative to normpdf?

You _could_ simply compute the PDF using the equation given in the reference
page for NORMPDF, but then you'd have to clearly explain in your code where
the equation came from and why you're using it instead of NORMPDF, so that
you remember what you did when you return to this code in six months.

--
Steve Lord
sl...@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

[Hugh]

"Steven_Lord" <sl...@mathworks.com> wrote in message <iv4bip$f3f$1...@newscl01ah.mathworks.com>...

Thanks Steve,

But isn't this what normpdf does anyway?

Just curious why you think calculating the nomrpdf equation directly would be faster?

[Steven_Lord]

"Hugh " <h_a_pa...@hotmail.com> wrote in message

news:iv4dq2$lqi$1...@newscl01ah.mathworks.com...

> "Steven_Lord" <sl...@mathworks.com> wrote in message
> <iv4bip$f3f$1...@newscl01ah.mathworks.com>...

*snip*

> Thanks Steve,
>
> But isn't this what normpdf does anyway?

Part of what NORMPDF does, yes. It also has to handle the case where you
don't specify mu or sigma (a small bit of overhead, mind you, but a small
bit of overhead N times can add up), and there is some (small) overhead from
calling NORMPDF (which again can add up.)

Personally, I would stop at explicitly creating the matrix first input and
calling NORMPDF once; but if speed is your main (only) concern, performing
the calculations yourself could be ever so slightly faster. [Cue Rune
commenting on the speed of MATLAB vs. C/C++ in 3 ... 2 ... 1 ...]

[Hugh]

"Steven_Lord" <sl...@mathworks.com> wrote in message <iv4f7c$qeb$1...@newscl01ah.mathworks.com>...

Thanks again Steve.

Good advice as always!

Luckily I have found that by passing mu and sigma as matrices I cut the calls to normpdf from 45milltion to 90,000 and the computation time from 10mins+ to under 10 secs?

It seems that thae array version of normpdf calculates almost as fast as calling it once with scalar parameters I can hardly believe this to be true but it works?

[Rune Allnor]

On Jul 7, 4:18 pm, "Steven_Lord" <sl...@mathworks.com> wrote:

> Personally, I would stop at explicitly creating the matrix first input and
> calling NORMPDF once; but if speed is your main (only) concern, performing
> the calculations yourself could be ever so slightly faster. [CueRune
> commenting on the speed of MATLAB vs. C/C++ in 3 ... 2 ... 1 ...]

Mock me as much you like, you know I am right: Matlab is *slow*.

Having said that, one thing that matlab *is* good at is
computations. The problem is everything else - control
loops, memory managment; anything that deviates from
array / matrix semantics...

Rune