Trying to understand area calculations in Gaussian and ExpModGauss Peaks

Share icon

I am trying to understand the area calculation in MPF V.2 and I am getting confused in the differences between the gaussian and ExpModGaussian areas are calculated.

As a baseline I am using Area of Gaussian = Height * C * sort(2*pi)
where c is the standard deviation

For a Gaussian Fit of a peak I get


Area = 437619
Height = 45343
Width = 5.4452

When I run the sums is appears that the width reported = sqrt(2)*C

In the ExpModGaussian

Area = 712608
Height = 84684
Width = 3.2445

When I run the sums it appears that the reported width = C (i.e. no sqrt(2) factor).

So a couple of questions:
Am I correct in assuming that the ExpModGaussian only alters the shape of the distribution and not the overall area?

From the peak functions.ipf file it appears as the sort(2) factor is correct for the Gaussian?
Is the reason there is no sqrt(2) in the ExpModGaussian is because it is normalized to area?

Just trying to understand.
The basic ExpModGauss peak shape is a Gaussian probability density convolved with an exponential probability density. That way, the convolution also has unit area.

The whole business with the Gaussian peak shape not using the standard deviation is historical in Igor (hysterical?).

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com

April 30, 2014 at 02:57 pm - Permalink

johnweeks wrote:

The whole business with the Gaussian peak shape not using the standard deviation is historical in Igor (hysterical?).


Differences in Gaussian shapes for normal probability versus spectroscopy are also noted here ...

http://www.igorexchange.com/node/4395

I always have to re-evaluate what case is being used for a "Gaussian" peak. Add to this is that Igor has a few other cases that follow neither convention. Perhaps Igor 7 can depreciate some "hysterical" stuff then? For example, standardize to use the function defined for the normal distribution curve or for the spectroscopy curve. The equations to convert between these two forms are well-defined. Depreciate anything else (and drop support in Igor 8 =:-0)

Gauss(x, mu, sigma) --> for normal probability curves ... OK
GaussS(x, position, half-width) --> for spectroscopy curves ... NEW
Gauss1D(w, x) --> pseudo Gaussian in 1D ... follows neither convention ... so depreciate
--> Gauss1N(w, x) --> for 1D normalized probability + base-line
Gauss2D(w, x, y) --> pseudo Gaussian in 2D (depreciated) ... follows neither convention .. so depreciate
--> Gauss2N(w, x, y) --> for 2D normalized probability + base-line

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

April 30, 2014 at 04:30 pm - Permalink

Quote:
I always have to re-evaluate what case is being used for a "Gaussian" peak. Add to this is that Igor has a few other cases that follow neither convention. Perhaps Igor 7 can depreciate some "hysterical" stuff then? For example, standardize to use the function defined for the normal distribution curve or for the spectroscopy curve. The equations to convert between these two forms are well-defined. Depreciate anything else (and drop support in Igor 8 =:-0)

You're right- it's a mess. But it's probably too late to get something with such implications into Igor 7. And you should know by now- we never drop *anything*. :)

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com

April 30, 2014 at 05:20 pm - Permalink

johnweeks wrote:
And you should know by now- we never drop *anything*. :)

Which really is a feature!
I recently had some igor code with a change date of 6/1998 and it just ran without any complaining.

Back to the subject on historical quirks.
The people from cmake have a concept called policies [1].
It tries to balances the wish for backward compatibility and proper behaviour for new users.

I'm not sure how that would translate to Igor. The #pragma rtGlobals statement does not sound right for the gaussian FWHM case.

[1]: http://www.cmake.org/Wiki/CMake/Policies

May 1, 2014 at 05:52 am - Permalink

Hi John,

You mentioned in your post the ever elusive Igor 7. Can you hint as to when that creature may see the light of day?

Andy

May 1, 2014 at 06:45 am - Permalink

johnweeks wrote:
... And you should know by now- we never drop *anything*. :)


I have an uncle who seems to follow this philosophy, and it's costing him a tidy sum in storage unit fees. :-)

I do however appreciate the steps taken to sustain backward compatibility, as duly noted by Thomas.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

May 1, 2014 at 08:01 am - Permalink