[Rd] RFC: log='z' for image, contour, persp?

Duncan Murdoch murdoch at stats.uwo.ca
Wed May 10 13:17:46 CEST 2006


On 5/10/2006 4:23 AM, Martin Maechler wrote:
>>>>>> "Duncan" == Duncan Murdoch <murdoch at stats.uwo.ca>
>>>>>>     on Tue, 09 May 2006 18:41:09 -0400 writes:
> 
>     Duncan> I've been thinking of adding the possibility of
>     Duncan> including "z" among the axes to be logged in image,
>     Duncan> contour, and persp.  In the first two, it would only
>     Duncan> affect where the breaks were set if they are
>     Duncan> calculated automatically; it would have a bigger
>     Duncan> effect in persp.
> 
>     Duncan> For example,
> 
>     Duncan> image(x, y, z, log="z")
> 
>     Duncan> would set 12 colours evenly spaced on a log scale of
>     Duncan> the z values.  (12 because that's the default).
> 
>     Duncan> We already support
> 
>     Duncan> image(x, y, z, log="x")
> 
>     Duncan> to scale the x axis (though there's a spurious
>     Duncan> warning; I'll fix that).
> 
>     Duncan> image(z, log="x")
> 
>     Duncan> fails because it tries to take a log of zero.
> 
>     Duncan> Does it seem like a good idea for these 3D functions
>     Duncan> to support log="z" the way 2D functions do?
> 
> Yes, I think it's a good idea.
> 
> You forgot to mention   filled.contour()
> which is  image() + "color - legend"
> For that one, it would be particularly useful to automatically
> get a "evenly space in log-scale" one.

Thanks for pointing that out.  This is a little tricky:  I think 
filled.contour would want evenly spaced contours, but use the axTicks() 
version of pretty labels on the legend; but contour() would probably 
want the contours themselves to be at nice round values.

It looks as though I'll need to think about adding a log=TRUE option to 
pretty(), to expose or duplicate the internal code that sets log axes. 
(axTicks is close, but I don't think it allows for automatic computation 
of axp[3]).

Duncan
> 
>     Duncan> Duncan Murdoch
> 
> Note that for things like the above, I have added
> a simple function lseq() in package 'sfsmisc' -- which I have
> contemplated moving to R.  Maybe this could happen at the same
> time and you could make use of it for the above.
> 
> Martin
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list