spikes in contour and persp (PR#327)

[Peter Dalgaard BSA]

ripley@stats.ox.ac.uk writes:

> > From: jlindsey@alpha.luc.ac.be
> > Date: Tue, 16 Nov 1999 08:57:00 +0100 (MET)
> > 
> > The following matrix of normed likelihoods should give a smooth
> > surface but instead gives a series of spikes in both persp and contour
> > (the dim labels are the axes values). I know an algorithm cannot be
> > infallible but it would be nice to have some parameters to control the
> > smoothing. (It takes close to an hour to produce this matrix on a
> > Pentium II 300mh. It was after that that it crashed with the Inf in my
> > previous bug message...)
> 
> 
> I am sorry, but I don't understand. contour does not do any
> smoothing, but interpolates assuming smoothness.  The data
> appears to me to be a series of spikes just off the diagonal, and not
> what contour thinks of as a smooth surface.  It is common to 
> interpolate the data from such a coarse grid before contouring.
> 
> persp just plots the data with visual linear interpolation.
> 

To elaborate a little: The contouring is of course algorithm
dependent.

Let's look at a section of the data:

    1   17    15    1     0    0  
    0    3    34   21     1    0  
    0    0     6   57    26    1  
    0    0     0   12    79   29  

One contouring method works by linear interpolation on triangles, so when
creating the line for, say z=25, it will draw four lines *around* 34,
then one connecting the 21-57 line, the 6-57, the 12-57 and the 12-79
and on the other end 21-26 (diag) 26-1 (vertical) 26-1 (horizontal) and 1-29.
This gives two disjoint contours and an apparent peak at 34. The
algorithm in R is pretty similar to this as far as I recall.

Alternatively one could have bilinear interpolation which would fit a
curve with a saddlepoint to the square

34 21
 6 57

and draw one connected contour. However, bilinear interpolation is a
bit of a pain, because the contours are not lines, but pieces of a
hyperbola, which is not nearly as easy to draw. And if the contour
level is close enough to 34, you'll get the peak effect anyway.

In any case, this is not a bug, it's an algorithm with shortcomings.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._