R help - Nov 2013 - `level' definition in `computeContour3d' (misc3d package)

I'd very much appreciate some help here: I'm in the process of
clarifying
whether I can use `computeContour3d' to derive estimates of the surface  
area of a single closed isosurface (and prospectively the enclosed  
volume). getting the surface area from the list of triangles returned by  
`computeContour3d' is straightforward but I've stumbled over the precise
meaning of `level' here. looking into the package, ultimately the level is  
used in the namespace function `faceType' which reads:

function (v, nx, ny, level, maxvol)
{
     if (level == maxvol)
         p <- v >= level
     else p <- v > level
     v[p] <- 1
     v[!p] <- 0
     v[-nx, -ny] + 2 * v[-1, -ny] + 4 * v[-1, -1] + 8 * v[-nx,
         -1]
}

my question: is the discrimination of the special case `level == maxvol'  
(or rather of everything else) really desirable? I would argue
that always testing for `v >= level' would be better. if I feed data with
discrete values (e.g. integer-valued) defined
on a coarse grid into `computeContour3d' it presently makes a big  
difference whether there is a single data point (e.g.) with a value larger
than `level' or not. consider the 1D example:

data1 <- c(0, 0, 1, 1, 1, 1, 1, 0, 0)
data2 <- c(0, 0, 1, 2, 1, 1, 1, 0, 0)

and level = 1

this defines the isocontour `level = 1' to lie at pos 3 and 7 in for data1  
but as lying at pos 4 in data2. actually I would like (and expect) to get  
the same isosurface for `data2' with this `level' setting. in short: the
meaning/definition of `level' changes depending on whether or not it is  
equal to `maxvol'. this is neither stated in the manpage nor is this  
desirable in my view. but maybe I miss something here. any clarification  
would be appreciated.

j.



--

On 13-11-09 8:50 AM, j. van den hoff wrote:
> I'd very much appreciate some help here: I'm in the process of
clarifying
> whether I can use `computeContour3d' to derive estimates of the surface
> area of a single closed isosurface (and prospectively the enclosed
> volume). getting the surface area from the list of triangles returned by
> `computeContour3d' is straightforward but I've stumbled over the
precise
> meaning of `level' here. looking into the package, ultimately the level
is
> used in the namespace function `faceType' which reads:
>
> function (v, nx, ny, level, maxvol)
> {
>       if (level == maxvol)
>           p <- v >= level
>       else p <- v > level
>       v[p] <- 1
>       v[!p] <- 0
>       v[-nx, -ny] + 2 * v[-1, -ny] + 4 * v[-1, -1] + 8 * v[-nx,
>           -1]
> }
>
> my question: is the discrimination of the special case `level ==
maxvol'
> (or rather of everything else) really desirable? I would argue
> that always testing for `v >= level' would be better. if I feed data
with
> discrete values (e.g. integer-valued) defined
> on a coarse grid into `computeContour3d' it presently makes a big
> difference whether there is a single data point (e.g.) with a value larger
> than `level' or not. consider the 1D example:
>
> data1 <- c(0, 0, 1, 1, 1, 1, 1, 0, 0)
> data2 <- c(0, 0, 1, 2, 1, 1, 1, 0, 0)
>
> and level = 1
>
> this defines the isocontour `level = 1' to lie at pos 3 and 7 in for
data1
> but as lying at pos 4 in data2. actually I would like (and expect) to get
> the same isosurface for `data2' with this `level' setting. in
short: the
> meaning/definition of `level' changes depending on whether or not it is
> equal to `maxvol'. this is neither stated in the manpage nor is this
> desirable in my view. but maybe I miss something here. any clarification
> would be appreciated.
I don't see why you'd expect the same output from those vectors, but 
since they aren't legal input to computeContour3d, maybe I don't know 
what you mean by them.  Could you put together a reproducible example 
that shows bad contours?

Duncan Murdoch
>
> j.
>
>
>
> --
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>