[SciPy-User] kriging module
Sat Nov 20 22:28:15 CST 2010
On Sat, Nov 20, 2010 at 5:35 PM, Robert Kern <email@example.com> wrote:
> On Sat, Nov 20, 2010 at 17:08, Gael Varoquaux
> <firstname.lastname@example.org> wrote:
> > On Sat, Nov 20, 2010 at 04:59:41PM -0600, Robert Kern wrote:
> >> > Sorry, I should have said 'Gaussian process regression', which is the
> >> > full name, and is an equivalent to Kriging. Gaussian processes in
> >> > themself are a very large class of probabilistic models.
> >> > AFAICT, PyMC does not have any Gaussian process regression, and it
> >> > seem a bit outside its scope.
> >> I'm pretty sure it does. See section 1.4 "Nonparametric regression"
> >> and 2.4 "Geostatistical example" in the GP User's Guide:
> >> http://pymc.googlecode.com/files/GPUserGuide.pdf
> > Yes, you are right. My bad. The good news is that it means that the name
> > is not too badly overloaded.
> > I see that they do the estimation by sampling the posterior, whereas the
> > proposed contribution in the scikit simply does a point estimate using
> > the scipy's optimizers. I guess that PyMC's approach gives a full
> > posterior estimate, and is thus richer than the point estimate, but I
> > would except it to be slower. I wonder if they are any other fundemental
> > differences (I don't know Gaussian processes terribly well).
> Well, the posterior is always Gaussian, so point estimates with 1-SD
> error bands characterize the posterior perfectly well! pymc.gp does
> point estimates, too. See the Mean.observe() method. It used to live
> as a separate package by another author before they decided to merge
> it into PyMC.
> But yes, kriging is a specialization of GP regression by another name.
> The main distint features of kriging are that the covariance functions
> usually take a particular form (a nonzero variance called the "nugget"
> infinitesimally off of 0 and increasing smoothly to a limiting value
> called the "sill" far from 0), and the covariance function is often
> estimated from the data. Oh, and no one outside of geostatistics uses
> the word "kriging". ;-)
Not to be argumentative, but this is why it may not make a ton of sense to
wrap "kriging" into a module that implements more general Gaussian process
People who are looking for a package to interpolate data using kriging are
going to expect to:
a) specify which type of covariance function they're using from a number of
commonly used ones,
b) fit this function from the observed data,
c) review the fit of this function and have manual control it function,
d) have a covariance function that varies depending on azimuth (Or at least
a way to test for the degree and direction of anisotropy in the observed
data and use this when interpolating),
d) use other related methods (such as co-kriging to incorporate multiple
variables, or stochastic simulation using the same covariance functions,
e) have lots of control over the search window used when interpolating
(which is a bit of a different topic)
>From a practical standpoint, the only reason to use kriging as an
interpolation method is so that you can incorporate lots of a-priori
information. No one should ever interpolate any data unless they know what
the result _should_ look like. The various "kriging" methods essentially
just give a lot of "knobs to tweak", so that you can build an interpolation
method that produces results that behaves in a certain way for a certain
case. It's all about incorporating a-priori information. Otherwise, just
use a radial basis function, or some other smooth interpolator.
I'm not trying to say that it's a bad thing to combine similar code, just be
aware that the first thing that someone's going to think when they hear
"kriging" is "How do I build and fit a variogram with this module?".
> Robert Kern
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
> SciPy-User mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-User