On Mon, Aug 22, 2011 at 7:17 PM, David Winsemius <[email protected]>wrote:
> > On Aug 22, 2011, at 6:26 PM, R. Michael Weylandt wrote: > > >> >> On Mon, Aug 22, 2011 at 4:57 PM, David Winsemius <[email protected]> >> wrote: >> >> On Aug 22, 2011, at 4:34 PM, David Winsemius wrote: >> >> >> On Aug 22, 2011, at 3:50 PM, R. Michael Weylandt wrote: >> >> Yes. The xCDF/yCDF objects that are returned by the ecdf function can be >> called like functions. >> >> Because they _are_ functions. >> >> > "function" %in% class(xCDF) >> [1] TRUE >> > is.function(xCDF) >> [1] TRUE >> >> You know, I spent a good 30 seconds trying to figure out how to put that, >> knowing that whatever I said someone would pounce on, yes it is a function >> on one hand, but it's not only a function on the other...the dangerous world >> of being the small fish in the semi-anonymous list serve pool...point >> definitely taken though. What's the official way to say it? "xCDF has a >> function class"? >> > > "xCDF is an R function." # would be how I would say it. > > The trick here is that ecdf-objects are computed on the basis of another > object in the workspace but the information is stored in the ecdf function's > environment. When you wrap that object in an additional call to the > "function()" function you may be making your implementation much more > fragile. The function , xCDF has the knots stored with it in its > environment. but the Fx function only has a reference to xCDF and no > environment other than the .Global.env, so there isn't much left if you then > remove xCDF, whereas removing x will leave xCDF entirely functional. > > > environment(xCDF) > <environment: 0x385705340> > > ls(env=environment(xCDF)) > [1] "f" "method" "n" "nobs" "x" "y" "yleft" "yright" > > environment(xCDF)$x > [1] -2.363555812 -2.036395899 -1.627785957 -1.554706917 -1.541211694 > [6] -1.290059870 -1.208761869 -1.027517109 -0.981711990 -0.848029056 > [11] -0.809689052 -0.678832827 -0.574025735 -0.554839320 -0.509889638 > [16] -0.502089844 -0.455731547 -0.424468236 -0.343728630 -0.300323734 > [21] -0.288451556 -0.188242567 -0.139732427 -0.137601990 -0.083517129 > [26] -0.009441695 0.018491182 0.063308320 0.094458225 0.145796550 > [31] 0.184200096 0.193462918 0.286655660 0.296894739 0.340814704 > [36] 0.436575933 0.445344391 0.455784057 0.609317046 0.684856461 > [41] 0.714905811 0.784777207 0.803642616 0.878443730 1.014727110 > [46] 1.182792891 1.544940127 1.859003832 2.852197035 3.049627080 > > environment(xCDF)$y > [1] 0.02 0.04 0.06 0.08 0.10 0.12 0.14 0.16 0.18 0.20 0.22 0.24 0.26 0.28 > [15] 0.30 0.32 0.34 0.36 0.38 0.40 0.42 0.44 0.46 0.48 0.50 0.52 0.54 0.56 > [29] 0.58 0.60 0.62 0.64 0.66 0.68 0.70 0.72 0.74 0.76 0.78 0.80 0.82 0.84 > [43] 0.86 0.88 0.90 0.92 0.94 0.96 0.98 1.00 > > My testing suggests that `save` function will retain the envirmonment but > the `dump` function will not. > > Thanks for all this. I'm gonna spend a little while longer figuring it out, but I've never been good with environments so it's seeming like its about time to force myself to buckle down. > > For example: >> >> x = rnrom(50); xCDF = ecdf(x); xCDF(0.3) >> # This value tells you what fraction of x is less than 0.3 >> >> You can also assign this behavior to a function: >> >> F <- function(z) { xCDF(z) } >> >> F does not inherit xCDF directly though and looses the step-function-ness >> of >> the xCDF object. (Compare plots of F and xCDF to see one consequence) >> >> Not correct. Steps are still there in the same locations. >> >> Yes, but >> >> > "stepfun" %in% class(xCDF) >> TRUE >> >> > "stepfun" %in% class(F) >> FALSE >> >> is what I meant. plot.stepfun() gives those nice little dots at the jumps >> that plot.function() doesn't -- hence my reference to the graph. It is an >> admittedly minor difference though. >> > > The plots looked identical to me. Not sure what difference you are > referring to. Really? Perhaps it's a recent update in R or a quirk of my machine: x = rnorm(50) xCDF = ecdf(x) xCdfFnc <- function(z){xCDF(z)} png("plots.png",width=4*480,height=4*480) layout(matrix(1:4,2,byrow=T)) plot.ecdf(xCDF,main="Default (plot.ecdf)") plot.stepfun(xCDF,main="plot.stepfun") graphics:::plot.function(xCDF,main="plot.function") plot(xCdfFnc,main="xCdfFnc Plot") dev.off() produces the image stored at http://tinypic.com/view.php?pic=2hyf3uv&s=7 on my machine. > sessionInfo() R version 2.13.1 (2011-07-08) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] C/en_US.UTF-8/C/C/C/C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] xts_0.8-2 zoo_1.7-2 loaded via a namespace (and not attached): [1] grid_2.13.1 lattice_0.19-31 tools_2.13.1 But yes, basically the same. > >> >> >> So yes, you can do subtraction on this basis >> >> x = rnrom(50); Fx = ecdf(x); Fx <- function(z) { xCDF(z) } >> >> You are adding an unnecessary function "layer". Try (after correcting the >> misspelling): >> >> xCDF(seq(-2,2,by=0.02)) == Fx(seq(-2,2,by=0.02)) # => creating Fx is >> superfluous >> >> x <- function(x){function(x) x} <==> x <- function(x){ x} >> >> "Turtles all the way down." >> >> Just a stupid typo: meant to define xCDF = ecdf(x) as before: I know the >> extra function term is silly. I do like turtles though...preferably in >> chocolate than soup >> >> >> >> y = rnrom(50); yCDF = ecdf(x); Fy <- function(z) { yCDF(z) } >> >> F <- function(z) {Fx(z) - Fy(z)} >> # F <- function(z) {xCDF(z)-yCDF(z)} # Another way to do the same thing >> >> As this would have this: >> >> F = function(z) xCDF(z)-yCDF(z) >> plot(seq(-2,2,by=0.02), F(seq(-2,2,by=0.02)) ,type="l") >> >> Interesting plot by the way. Unit steps at Gaussian random intervals. I'm >> not sure my intuition would have gotten there all on its own. I guess that >> arises from the discreteness of the sampling. I wasn't think that ecdf was >> the inverse function but seem to remember someone (some bloke named >> Weylandt, now that I check) saying as much earlier in the day. >> >> >> I take it back. Not necessarily unit jumps, Quantized, yes, but the sample >> I'm looking at has jumps of 0,1,2, and 3 * 0.02 units. Poisson? (Probably >> a homework problem in Feller.) >> >> That is a fun little puzzle: now I have something to ponder on the train >> tonight. >> >> And don't listen to that Weylandt bloke, I have it on quite good authority >> he doesn't actually know what he's doing. >> >> (By the way, is this a reference to the question about qexp() earlier >> today? I hope I said that was the inverse CDF, not the CDF itself: if so, I >> owe someone quite an apology...) >> > > It was, but not in a negative sense. The notion that the quantile function > is the inverse of the CDF seemed perfectly fine to me. One maps from > probability [0,1] to the outside world, the other maps from a set of > observations to probability. > > I was remarking on the fact that the construction of two eCDFs at equal > quantiles made for some interesting properties in the differences of such > eCDFs. Random musings on random walks, you could say. > > -- > David. > > >> >> (who has learned not to tempt the gods with imprecise references to R's >> class functionality :-) ) >> > > David 'not a god" Winsemius, MD > West Hartford, CT > > Michael [[alternative HTML version deleted]] ______________________________________________ [email protected] 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.
