Re: [Rd] arima
Pierre- I wonder how many people have to submit this concern before someone takes care of the problem. I may have been the first to point this out because I got a reply from an R core member that was rude, to say the least. Now there are no responses to this query. I set up a page to keep track of R problems with time series ... spread the word: http://www.stat.pitt.edu/stoffer/tsa2/Rissues.htm . You will also find some fixes there, and you will see that I point out some inconsistencies [e.g., if you use ar(), the term intercept is used differently than in arima()]. Unfortunately, that won't help with the fGarch problem - you should write the maintainers: Rmetrics-core at r-project.org. Pierre Chaussé wrote: > > Hi, > > I have a suggestion for the fonction arima and arima0. I think you > should not call the constant an intercept because it creates confusion. > It is not really an intercept but a mean. For an AR(1) the intercept mu > should be defined as: > > X(t)=mu + phi X(t-1) + e(t) > > What you call intercept mu is rather defined as > > (X(t)-mu) = phi (X(t-1)-mu)) + e(t) > > which is not a common way to define an intercept. There is an error in > the fGarch's predict() because of that. I think you should just be more > explicit. > > thank you > > Pierre Chaussé > economics department > UQÀM > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > - The power of accurate observation is commonly called cynicism by those who have not got it. George Bernard Shaw -- View this message in context: http://www.nabble.com/arima-tp23179485p23464456.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Vignettes with missing or empty \VignetteIndexEntry:
> Christophe Dutang writes:
> Hi,
> I have a problem when checking the package 'probdistr' (on probability
> distributions).
> I got this warning
> * checking index information ... WARNING
> Vignettes with missing or empty \VignetteIndexEntry:
> [1] "probdistr-chi""probdistr-contextra" "probdistr-discrete"
> [4] "probdistr-discrextra" "probdistr-exp""probdistr-
> finitesupp"
> [7] "probdistr-gaussian" "probdistr-general""probdistr-gumbel"
> [10] "probdistr-intro" "probdistr-logis" "probdistr-math"
> [13] "probdistr-misc" "probdistr-mult" "probdistr-pareto"
> [16] "probdistr-student"
> See the information on INDEX files and package subdirectories in the
> chapter 'Creating R packages' of the 'Writing R Extensions' manual.
> The warning tells me \VignetteIndexEntry is missing however there is
> one in probdistr-main.Rnw (Sweave file calling all other files via
> \SweaveInput{probdistr-X}). Let us note this file is not listed in
> the above files...
> But the build is ok
> * checking for file 'pkg/DESCRIPTION' ... OK
> * preparing 'pkg':
> * checking DESCRIPTION meta-information ... OK
> * installing the package to re-build vignettes
> * Installing *source* package ‘probdistr’ ...
> ** R
> ** inst
> ** help
> *** installing help indices
Building/Updating help pages for package 'probdistr'
> Formats: text html latex example
>codeforplot texthtmllatex example
> ** building package indices ...
> * DONE (probdistr)
> * creating vignettes ... OK
> * removing junk files
> * checking for LF line-endings in source and make files
> * checking for empty or unneeded directories
> * building 'probdistr_1.00.tar.gz'
> Does someone have an idea about this?
Sure. The QC tools have no idea about \SweaveInput, and think that each
.Rnw should have a \VignetteIndexEntry.
-k
> Thanks in advance
> Christophe
> PS : files are available on R-forge
> --
> Christophe Dutang
> Ph. D. student at ISFA, Lyon, France
> website: http://dutangc.free.fr
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] In C, a fast way to slice a vector?
Impressive stuff. Nice to see people giving some though to this.
I will explore the packages you mentioned.
Thank you
Saptarshi Guha
On Mon, May 11, 2009 at 12:37 AM, Patrick Aboyoun wrote:
> Saptarshi,
> I know of two alternatives you can use to do fast extraction of consecutive
> subsequences of a vector:
>
> 1) Fast copy: The method you mentioned of creating a memcpy'd vector
> 2) Pointer management: Creating an externalptr object in R and manage the
> start and end of your data
>
> If you are looking for a prototyping environment to try, I recommend using
> the IRanges and Biostrings packages from the Bioconductor project. The
> IRanges package contains a function called subseq for performing 1) on all
> basic vector types (raw, logical, integer, etc.) and Biostrings package
> contains a subseq method on an externalptr based class that implements 2.
>
> I was going to lobby R core members quietly about adding something akin to
> subseq from IRanges into base R since it is extremely useful for all long
> vectors and could replace all a:b calls with a <= b in R code, but this
> publicity can't hurt.
>
> Here is an example:
>
>> source("http://bioconductor.org/biocLite.R";)
>> biocLite(c("IRanges", "Biostrings"))
>
> << download output omitted >>
>>
>> suppressMessages(library(Biostrings))
>> x <- rep(charToRaw("a"), 1e7)
>> y <- BString(rawToChar(x))
>> suppressMessages(library(Biostrings))
>> x <- rep(charToRaw("a"), 1e7)
>> y <- BString(rawToChar(x))
>> system.time(x[13:1e7])
>
> user system elapsed
> 0.304 0.073 0.378
>>
>> system.time(subseq(x, 13))
>
> user system elapsed
> 0.011 0.007 0.019
>>
>> system.time(subseq(y, 13))
>
> user system elapsed
> 0.003 0.000 0.004
>>
>> identical(x[13:1e7], subseq(x, 13))
>
> [1] TRUE
>>
>> identical(x[13:1e7], charToRaw(as.character(subseq(y, 13
>
> [1] TRUE
>>
>> sessionInfo()
>
> R version 2.10.0 Under development (unstable) (2009-05-08 r48504)
> i386-apple-darwin9.6.0
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] Biostrings_2.13.5 IRanges_1.3.5
>
> loaded via a namespace (and not attached):
> [1] Biobase_2.5.2
>
>
>
> Quoting Saptarshi Guha :
>
>> Hello,
>> Suppose in the following code,
>> PROTECT(sr = R_tryEval( ))
>>
>> sr is a RAWSXP vector. I wish to return another RAWSXP starting at
>> position 13 onwards (base=0).
>>
>> I could create another RAWSXP of the correct length and then memcpy
>> the required bytes and length to this new one.
>>
>> However is there a more efficient method?
>>
>> Regards
>> Saptarshi Guha
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion for extending ?as.factor
> "PS" == Petr Savicky
> on Sun, 10 May 2009 13:52:53 +0200 writes:
PS> On Sat, May 09, 2009 at 10:55:17PM +0200, Martin Maechler wrote:
PS> [...]
>> If'd revert to such a solution,
>> we'd have to get back to Peter's point about the issue that
>> he'd think table(.) should be more tolerant than as.character()
>> about "almost equality".
>> For compatibility reasons, we could also return back to the
>> reasoning that useR should use {something like}
>> table(signif(x, 14))
>> instead of
>> table(x)
>> for numeric x in "typical" cases.
PS> In the released versions 2.8.1 and 2.9.0, function factor() satisfies
PS> identical(as.character(factor(x)), as.character(x))(*)
PS> for all numeric x. This follows from the code (levels are computed by
PS> as.character() from unmodified input values) and may be verified
PS> even for the problematic cases, for example
PS> x <- (0.3 + 2e-16 * c(-2,-1,1,2))
PS> factor(x)
PS> # [1] 0.300 0.3 0.3 0.300
PS> # Levels: 0.300 0.3 0.3 0.300
PS> as.character(x)
PS> # [1] "0.300" "0.3" "0.3"
PS> # [4] "0.300"
PS> identical(as.character(factor(x)), as.character(x))
PS> # [1] TRUE
PS> In my opinion, it is reasonable to require that (*) be
PS> preserved also in future versions of R.
PS> Function as.character(x) has disadvantages. Besides of
PS> the platform dependence, it also does not always perform
PS> rounding needed to eliminate FP errors. Usually,
PS> as.character(x) rounds to at most 15 digits, so, we get,
PS> for example
PS> as.character(0.1 + 0.2) # [1] "0.3"
PS> as required. However, there are also exceptions, for example
PS> as.character(1e19 + 1e5) # [1] "10100352"
PS> Here, the number is printed exactly, so the resulting
PS> string contains the FP error caused by the fact that
PS> 1e19 + 1e5 has more than 53 significant digits in binary
PS> representation, namely 59.
PS> binary representation of 1e19 + 1e5 is
PS> 100010101100011100100011010010001000100111101010
PS> binary representation of 10100352 is
PS> 100010101100011100100011010010001000100110001000
PS> However, as.character(x) seems to do enough rounding for
PS> most purposes, otherwise it would not be suitable as the
PS> basic numeric to character conversion. If table() needs
PS> factor() with a different conversion than
PS> as.character(x), it may be done explicitly as discussed
PS> by Martin above.
PS> So, i suggest to use as.character() as the default
PS> conversion in factor(), so that
PS> identical(as.character(factor(x)), as.character(x)) is
PS> satisfied for the default usage of factor().
PS> Of course, i appreciate, if factor() has parameters,
PS> which allow better control of the underlying conversion,
PS> as it is done in the current development versions.
The version I have committed a few hours ago is indeed a much
re-simplified version, using as.character(.) explicitly
and consequently no longer providing the extra optional
arguments that we have had for a couple of days.
Keeping such a basic function factor() as simple as possible
seems a good strategy to me.
Martin Maechler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion for extending ?as.factor
On Mon, May 11, 2009 at 05:06:38PM +0200, Martin Maechler wrote:
[...]
> The version I have committed a few hours ago is indeed a much
> re-simplified version, using as.character(.) explicitly
> and consequently no longer providing the extra optional
> arguments that we have had for a couple of days.
>
> Keeping such a basic function factor() as simple as possible
> seems a good strategy to me.
OK. I understand the argument of simplicity. So, factor(x) is just
a compressed encoding of as.character(x), where each value is stored
only once. This sounds good to me.
Let me go back to the original purpose of this thread: suggestion for
extending ?as.factor
I think that somewhere in the help page, we could have something like
Using factor() to a numeric vector should be done with caution. The
information in x is preserved to the extent to which it is preserved
in as.character(x). If this leads to too many different levels due to minor
differences among the input numbers, it is suggested to use something like
factor(signif(x, digits)) or factor(round(x, digits)), where the number of
decimal digits appropriate for a given application should be used.
Let me point out that the following sentence from Warning is not exactly correct
as it is in svn at the moment. So, i suggest to add the word "approximately" to
the place marked with square brackets and add one more sentence of explanation
marked also by square brackets.
To transform a factor \code{f} to [approximately]
its original numeric values, \code{as.numeric(levels(f))[f]} is
recommended and slightly more efficient than
\code{as.numeric(as.character(f))}.
[Note that the original values may be extracted only to the precision
used in as.character(x), which is typically 15 decimal digits.]
Petr.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Predict function npindex and npindexbw (PR#13695)
Full_Name: Maxime To Version: 2.9 OS: WIndows Submission from: (NULL) (81.57.236.122) I am using the npindex and npindexbw fubctions of the NP package. I would like to compute the predicted values of the model and tried to use the predict function for this purpose but the function only gives me the summary of the model but no vector of predicted values as with any other model. Simply using the code of the example, it gives: set.seed(12345) n <- 100 x1 <- runif(n, min=-1, max=1) x2 <- runif(n, min=-1, max=1) y <- x1 - x2 + rnorm(n) bw <- npindexbw(formula=y~x1+x2) summary(bw) predict(bw) You will see that the results of the summary and the predict function are the same. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [macosx] improving quartz & Aqua Tk behaviour outside of RGui
A couple of weeks ago I posted a trick in R-help on improving Quartz
behaviour in the command line version of R:
http://tolstoy.newcastle.edu.au/R/e6/help/09/04/12948.html .
Works with Aqua Tcl/Tk 8.5 too, but I discovered one annoying
side-effect. After having a Tk dialog open (and using it) for a while,
the R process starts eating more than 50% cpu on my PPC G4, using
either the 8.4 or the 8.5 Tcl/Tk libraries. (I'm currently running R
2.8.1 .)
This does NOT happen when running the exact same code in the same
commandline R version with the 8.4 X11 Tcl/Tk libraries, nor when I
run the Quartz version in R-GUI.
For completeness, here's the Tcl/Tk function:
dialog.test <- function(wait=FALSE)
{
with3 <- function( data1, data2=.GlobalEnv, expr )
{
attach(data1)
attach(data2)
on.exit( detach(data1), add= FALSE )
on.exit( detach(data2), add= TRUE )
try( eval( substitute(expr), parent.frame() ) )
}
require(tcltk) || stop("tcltk support is absent")
tt <- tktoplevel()
tkwm.title(tt,"VG1 tests")
tt.done <- tclVar("0")
name <- paste('dialog.test',as.character(tt$ID), sep='')
assign( name, tt, env=tdialog.env )
dialogVals<-get("dialogVals", env=RJVB.env)
data<-tclVar(dialogVals[1])
crit<-tclVar(dialogVals[2])
eval1st<-tclVar(dialogVals[9])
func<-tclVar(dialogVals[3])
args<-tclVar(dialogVals[4])
args2<-tclVar(dialogVals[5])
acomm<-tclVar(dialogVals[8])
sumvar <- tclVar(dialogVals[7])
done <- tclVar(0)
savecmd<-tclVar(dialogVals[6]);
devvar <- tclVar( dev.cur() )
theData <- ""
reset <- function()
{
tclvalue(data)<-""
tclvalue(crit)<-""
tclvalue(eval1st)<-""
tclvalue(func)<-""
tclvalue(args)<-""
tclvalue(args2)<-""
tclvalue(acomm)<-""
tclvalue(sumvar)<-"0"
}
doSource <- function()
{
fileN <- tclvalue( tkgetOpenFile() )
if( fileN != "" ){
try( source(fileN) )
}
}
dfInfo <- function(fnc)
{
## notice that tclvalue() is correct here, since it is the
## string representation of xvar and yvar that is being
## displayed in the entry fields
dataf <- tclvalue(data)
crit <- tclvalue(crit)
eval1st <- tclvalue(eval1st)
if( is.null(crit) | !strlen(crit) ){
theData <- paste( dataf )
assign( "Selected.Cases", "", env=RJVB.env )
}
else{
theData <- paste( "SelectCases(", dataf, ",\"", crit,
"\")" )
}
cmd<-paste( fnc, "( ", theData, " )" )
try(
cmd<-parse( text=cmd )
);
print( paste( "###", cmd ) )
print( try( eval(cmd, envir=.GlobalEnv) ) )
cmd
}
build <- function()
{
## notice that tclvalue() is correct here, since it is the
## string representation of xvar and yvar that is being
## displayed in the entry fields
dataf <- tclvalue(data)
crit <- tclvalue(crit)
eval1st <- tclvalue(eval1st)
func <- tclvalue(func)
args <- tclvalue(args)
args2 <- tclvalue(args2)
acomm <- tclvalue(acomm)
summ <- as.logical(tclObj(sumvar))
assign( "dialogVals",
c(dataf,crit,func,args,args2,dialogVals[6],tclvalue(sumvar), acomm,
eval1st ), env=RJVB.env )
if( is.null(crit) | !strlen(crit) ){
theData <- paste( dataf )
assign( "Selected.Cases", "", env=RJVB.env )
}
else{
theData <- paste( "SelectCases(", dataf, ",\"", crit,
"\")" )
}
if( is.null(acomm) | is.na(acomm) | !strlen(acomm) ){
acomm <- ""
}
else{
acomm <- paste( ", add.comment=\"", acomm, "\"" )
}
if( summ ){
cmd<-paste( "with3( ", theData, ", tkdial.env, summary(
last.dialog.result<-", func, "(", args, ",", args2, acomm, ") ) )" )
# cmd<-paste( "with2( ", theData, ", summary(
last.dialog.result<-", func, "(", args, ",", args2, acomm, ") ) )" )
}
else{
cmd<-paste( "with3( ", theData, ", tkdial.env,
last.dialog.result<-", func, "(", args, ",", args2, acomm, ") )" )
#
Re: [Rd] Predict function npindex and npindexbw (PR#13695)
maxime...@ensae.fr wrote: Full_Name: Maxime To Version: 2.9 OS: WIndows Submission from: (NULL) (81.57.236.122) I am using the npindex and npindexbw fubctions of the NP package. I would like to compute the predicted values of the model and tried to use the predict function for this purpose but the function only gives me the summary of the model but no vector of predicted values as with any other model. Simply using the code of the example, it gives: set.seed(12345) n <- 100 x1 <- runif(n, min=-1, max=1) x2 <- runif(n, min=-1, max=1) y <- x1 - x2 + rnorm(n) bw <- npindexbw(formula=y~x1+x2) summary(bw) predict(bw) You will see that the results of the summary and the predict function are the same. You need to take this up with the package maintainer. This is not a bug in R itself and cannot be handled via the bug report system. -- 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 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
