Re: [Rd] Interface between fractal geometry and statistics
2008/7/4 Ted <[EMAIL PROTECTED]>: > Are there any packages that help with statistical analysis in situations where > fractal geometry is relevant? Perhaps something that supports computation of > fractal related statistics, such as the Hurst exponent or fractal dimension? tseriesChaos has functions for estimating correlation dimension on an observed (long) time series. > Or perhaps which support obvious tasks such as taking samples from a dataset > at different levels of granularity (such as sampling spatial data at cm, m, km > spatial resolution, or sampling daily time series at weekly, monthly, quaterly > or annual resolution)? For time series, look for 'aggregate'. f. > > Thanks > > Ted > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Antonio, Fabio Di Narzo Ph.D. student at Department of Statistical Sciences University of Bologna, Italy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [[ vs. .subset2
Gabor Grothendieck wrote:
Not really. The point of this is that promises seem to be
screwing up in conjunction with [[ but in light of the fact
that .subset2 works it suggests that there might be a better
implementation of [[
Not really; .subset2() is a shortcut that bypasses method dispatch, so
not a drop-in replacement for "[[". You also have
> test3 <- function(pf = parent.frame()) "[[.data.frame"(BOD, pf$idx)
> test3()
[1] 8.3 10.3 19.0 16.0 15.6 19.8
Something appears not quite right, but an easy workaround is to force
the promise:
> test4 <- function(pf = parent.frame()) {pf;BOD[[pf$idx]]}
> test4()
[1] 8.3 10.3 19.0 16.0 15.6 19.8
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Editing the "..." argument
Dear all, I'd like tweaking the ... arguments that one user can pass in my function for fitting a model. More precisely, my objective function is (really) problematic to optimize using the "optim" function. Consequently, I'd like to add in the "control" argument of the latter function a "ndeps = rep(something, #par)" and/or "parscale = something" if the user has not specified it already. Do you know a way to deal with this point? In advance, thanks. Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Editing the "..." argument
On 05/07/2008 1:55 PM, Mathieu Ribatet wrote:
Dear all,
I'd like tweaking the ... arguments that one user can pass in my
function for fitting a model. More precisely, my objective function is
(really) problematic to optimize using the "optim" function.
Consequently, I'd like to add in the "control" argument of the latter
function a "ndeps = rep(something, #par)" and/or "parscale = something"
if the user has not specified it already.
Do you know a way to deal with this point?
In advance, thanks.
It's generally not necessary to edit the ... args, but one way to do it
is like this:
dots <- list(...)
# do some editing
# instead of optim(a, b, ...), now you do
do.call(optim, c(list(a, b), dots))
In the particular example you gave, I wouldn't do this; I'd give control
as an arg to your function, and just edit that. For example,
myoptim <- function(control = list(), ...) {
if (is.null(control$ndeps)) control$ndeps <- rep(something, par)
if (is.null(control$parscale)) control$parscale <- something
optim(control=control, ...)
}
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [.data.frame speedup
> "TH" == Tim Hesterberg <[EMAIL PROTECTED]>
> on Thu, 3 Jul 2008 17:04:24 -0700 writes:
TH> I made a couple of a changes from the previous version:
TH> - don't use functions anyMissing or notSorted (which aren't in base R)
TH> - don't check for dup.row.names attribute (need to modify other
functions
TH> before that is useful)
TH> I have not tested this with a wide variety of inputs; I'm assuming that
TH> you have some regression tests.
yes, we do (and they are part of the R source).
TH> Here are the file differences. Let me know if you'd like a different
TH> format.
TH> $ diff -c dataframe.R dataframe2.R
TH> *** dataframe.RThu Jul 3 15:48:12 2008
TH> --- dataframe2.RThu Jul 3 16:36:46 2008
...
context diff is fine (I typically use '-u' but that's not important).
>From your patch,
I've currently ended in this "patch" :
--- dataframe.R.~19~2008-07-03 02:13:21.000163000 +0200
+++ dataframe.R 2008-07-05 13:02:33.29000 +0200
@@ -579,14 +579,18 @@
## row names might have NAs.
if(is.null(rows)) rows <- attr(xx, "row.names")
rows <- rows[i]
- if((ina <- any(is.na(rows))) | (dup <- any(duplicated(rows {
- ## both will coerce integer 'rows' to character:
- if (!dup && is.character(rows)) dup <- "NA" %in% rows
- if(ina)
- rows[is.na(rows)] <- "NA"
- if(dup)
- rows <- make.unique(as.character(rows))
- }
+
+ ## Do not want to check for duplicates if don't need to
+ noDuplicateRowNames <-
+ (is.logical(i) || (li <- length(i)) < 2 ||
+(is.numeric(i) && (min(0, i, na.rm=TRUE) < 0 ||
+ (!any(is.na(i)) && all(i[-li] < i[-1L])
+ ## TODO: is.unsorted(., strict=FALSE/TRUE)
+ if(any(is.na(rows)))
+ rows[is.na(rows)] <- "NA" # coerces to integer
+ if(!noDuplicateRowNames && any(duplicated(rows)))
+ rows <- make.unique(as.character(rows)) # coerces to integer
+
## new in 1.8.0 -- might have duplicate columns
if(any(duplicated(nm <- names(x names(x) <- make.unique(nm)
if(is.null(rows)) rows <- attr(xx, "row.names")[i]
TH> Here's some code for testing, and timings
.
I've rationalized (wrote functions) and slightly extended your
tests, they are now public at
ftp://ftp.stat.math.ethz.ch/U/maechler/R/data.frame-TH-ex.R
Unfortunately, they show that "the speedup" is negative in some
cases, e.g. for the 'i <- 1:n' case for n <- 1000 or 1.
I've replicated every system.time() 12 times, to get a sense of
the precision, and that's still the conclusion.
In other words, your proposed 'noDuplicateRowNames'
computations are sometimes more expensive than the duplicated(.)
call they replace.
To me, that means that the whole exercise was probbaly in vain:
We are not making the code more complicated if it's not a
uniform improvement. Too bad.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
