[R] Puzzled with contour()

[Martin Maechler]

>>>>> "Duncan" == Duncan Murdoch <murdoch at stats.uwo.ca>
>>>>>     on Tue, 27 Jun 2006 08:58:59 -0400 writes:

    Duncan> On 6/27/2006 8:40 AM, Gabor Grothendieck wrote:
    >> On 6/27/06, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
    >>> >>>>> "Gabor" == Gabor Grothendieck <ggrothendieck at gmail.com>
    >>> >>>>>     on Mon, 26 Jun 2006 11:28:48 -0400 writes:
    >>> 
    Gabor> I think its often the case that one has 3 tuples and does not know
    Gabor> how to use contour with that; so, it would be nice if the contour
    Gabor> help page gave advice and an example and a pointer to the relevant
    Gabor> functions if it cannot be done by contour.
    >>> 
    >>> Yes, but even more importantly,
    >>> what  help(contour) should really have is a \code{\link[lattice]{contourplot}}
    >>> since contourplot() from package 'lattice'
    >>> can deal well excellently with the situation Ajay has:
    >>> 

    Duncan> [ deletions ]

    >> Or perhaps contour should be extended so that it can handle triples
    >> giving the capability directly in base graphics.  I think that that is what
    >> many people really expect.

    Duncan> The problem here is that most users are happy enough
    Duncan> with the akima or contourplot implementations, so
    Duncan> there isn't much motivation to spend several hours
    Duncan> doing the necessary work.  But if you want to
    Duncan> contribute this, please do.

But also consider that --- since the beginning of time or so ---
the triad of
      contour(), image(), and persp()
have had an (almost?) identical way of dealing with  (x,y,z)
{and related arguments}.

So we would want a change using a helper function that
can be used in all three cases {and BTW, that helper function
would use  xyz.coords() - similarly to what happens in
scatterplot3d() {in the pkg of the same name}.

    Duncan> Be careful about where you get the code: the interp
    Duncan> implementation in akima is not licensed freely
    Duncan> enough to be included in R ("no commercial
    Duncan> use"). The one in lattice is GPL'd, so it should be
    Duncan> fine.

and I agree that making that functionality part of ``base R''
(would be package 'grDevices') is something quite desirable.
Reiterating Duncan: Contributions are welcome, particularly if
they are patches against R-devel (and contain updated help files).

    Duncan> Duncan Murdoch

Martin Maechler