j. van den hoff
2013-Nov-09 13:50 UTC
[R] `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. --
Duncan Murdoch
2013-Nov-09 16:16 UTC
[R] `level' definition in `computeContour3d' (misc3d package)
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. >