Re: [Rd] CCF and ACF
Thank you Gabor, by the way I have checked in the Matlab GARCH toolbox, the crosscorrelation function is reversed with respect to R, I think it would be useful for the users to have documented the way CCF is computed. Simone On 10/2/06, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > Using "ts" objects these can be written in the following consistent > manner: > > > sum(ts(x) * lag(ts(x)) / sum(ts(x)^2)) > [1] -0.2648633 > > > sum(ts(x) * lag(ts(y)) / sqrt(sum(ts(y)^2) * sum(ts(x)^2))) > [1] 0.5930216 > > On 10/2/06, Simone Giannerini <[EMAIL PROTECTED]> wrote: > > Dear all, > > > > given two numeric vectors x and y, the ACF(x) at lag k is > > cor(x(t),x(t+k)) while the CCF(x,y) at lag k is cor(x(t),y(t-k)). See > > below for a simple example. > > > > > set.seed(1) > > > x <- rnorm(10) > > > y <- rnorm(10) > > > x > > [1] -0.6264538 0.1836433 -0.8356286 1.5952808 0.3295078 -0.8204684 > > 0.4874291 0.7383247 0.5757814 -0.3053884 > > > y > > [1] 1.51178117 0.38984324 -0.62124058 -2.21469989 1.12493092 > > -0.04493361 -0.01619026 0.94383621 0.82122120 0.59390132 > > > x <- x - mean(x); > > > y <- y -mean(y); > > > > ## ACF OF x(t) > > > print(acf(x,lag=2,plot=F),digits=5)) > > > > Autocorrelations of series 'x', by lag > > > >012 > > 1.0 -0.26486 -0.25352 > > > > ## For Instance ACF(x) at lag 1 is Corr(x(t),x(t+1)): > > > > > sum(x[1:9]*x[2:10])/sum(x^2) > > [1] -0.2648633 > > > > ## whereas CCF(x,y) at lag 1 is Corr(x(t),y(t-1)) > > > ccf(x,y,lag=2,plot=F) > > > > Autocorrelations of series 'X', by lag > > > >-2 -1 0 1 2 > > -0.139 0.593 -0.377 -0.382 0.116 > > > > > sum(x[1:9]*y[2:10])/sqrt(sum(x^2)*sum(y^2)) > > > > [1] 0.5930216 > > > > > sum(x[2:10]*y[1:9])/sqrt(sum(x^2)*sum(y^2)) > > [1] -0.3822885 > > > > from a quick survey on textbooks (Brockwell and Davis, Chatfield, > > Fuller) it looks like different authors use different conventions so > > that I think that it would be nice to clarify this in the > > documentation. > > > > Ciao > > > > Simone > > > > > R.version > > _ > > platform i386-pc-mingw32 > > arch i386 > > os mingw32 > > system i386, mingw32 > > status beta > > major 2 > > minor 4.0 > > year 2006 > > month 09 > > day20 > > svn rev39421 > > language R > > version.string R version 2.4.0 beta (2006-09-20 r39421) > > > > > Sys.getlocale() > > [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United > > States.1252;LC_MONETARY=English_United > > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252" > > > > > > __ > > > > Simone Giannerini > > Dipartimento di Scienze Statistiche "Paolo Fortunati" > > Universita' di Bologna > > Via delle belle arti 41 - 40126 Bologna, ITALY > > Tel: +39 051 2098262 Fax: +39 051 232153 > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in X11 (PR#9272)
Full_Name: Frank Schäffer Version: 2.3.1 OS: Ubuntu 6.10 (Edgy Eft) Submission from: (NULL) (86.56.0.173) [EMAIL PROTECTED]:~$ R R : Copyright 2006, The R Foundation for Statistical Computing Version 2.3.1 (2006-06-01) ISBN 3-900051-07-0 R ist freie Software und kommt OHNE JEGLICHE GARANTIE. Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten. Tippen Sie 'license()' or 'licence()' für Details dazu. R ist ein Gemeinschaftsprojekt mit vielen Beitragenden. Tippen Sie 'contributors()' für mehr Information und 'citation()', um zu erfahren, wie R oder R packages in Publikationen zitiert werden können. Tippen Sie 'demo()' für einige Demos, 'help()' für on-line Hilfe, oder 'help.start()' für eine HTML Browserschnittstelle zur Hilfe. Tippen Sie 'q()', um R zu verlassen. > plot(2,3) Fehler in X11() : kann keine X11 Schriften finden Bitte Fontpath überprüfen. "Translated to english" Error in X11() : could not find any X11 fonts Check that the Font Path is correct. This occurs at every time and also if I type demo(graphics). This appear at both native English language-pack or German language-pack delivered with ubuntu 6.10. Best regards Frank __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in X11 (PR#9272)
[EMAIL PROTECTED] writes: > Full_Name: Frank Schäffer > Version: 2.3.1 > OS: Ubuntu 6.10 (Edgy Eft) > Submission from: (NULL) (86.56.0.173) > > > [EMAIL PROTECTED]:~$ R > > R : Copyright 2006, The R Foundation for Statistical Computing > Version 2.3.1 (2006-06-01) > ISBN 3-900051-07-0 > > R ist freie Software und kommt OHNE JEGLICHE GARANTIE. > Sie sind eingeladen, es unter bestimmten Bedingungen weiter zu verbreiten. > Tippen Sie 'license()' or 'licence()' für Details dazu. > > R ist ein Gemeinschaftsprojekt mit vielen Beitragenden. > Tippen Sie 'contributors()' für mehr Information und 'citation()', > um zu erfahren, wie R oder R packages in Publikationen zitiert werden können. > > Tippen Sie 'demo()' für einige Demos, 'help()' für on-line Hilfe, oder > 'help.start()' für eine HTML Browserschnittstelle zur Hilfe. > Tippen Sie 'q()', um R zu verlassen. > > > plot(2,3) > Fehler in X11() : kann keine X11 Schriften finden > Bitte Fontpath überprüfen. > > "Translated to english" > Error in X11() : could not find any X11 fonts > Check that the Font Path is correct. > > This occurs at every time and also if I type demo(graphics). This appear at > both > native English language-pack or German language-pack delivered with ubuntu > 6.10. The most obvious guess is that you do not have the X11 fonts installed that R needs. That is an installation problem, not a bug in R. -- 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
Re: [Rd] Possible bug in Rcons_vprintf
Martin Maechler wrote:
> Thanks, Jeffrey,
>
> that (change) looks very logical, reasonable, ...
> and I'll commit a patch to R-devel ASAP.
>
> On the other hand, I'm currently not intending to port the fix
> to the currently "deep frozen" R-2.4-branch [because "you never know ..."]
> unless you can argue a bit more why the change seems important
> (or at least can demonstrate bogous behavior that is fixed by it).
Not a big deal at the moment... although I would have argued for its
inclusion into R 2.4 if rJava, a well established package used by JGR,
demonstrated bogus behavior... because it does depend on R_WriteConsole,
but it turns out that rjava ignores the second argument defining the
length of the buffer to be printed. Is this appropriate?
rJava is making an assumption that in a call to R_WriteConsole, the
buffer is always null terminated, and this seems supported by the R
source. The following grep output on R-2-4-branch (but probably in
R-trunk, too) shows that each call to R_WriteConsole *does* pass
null-terminated strings:
# some of the output has been edited
$ find . -follow -name '*.[ch]' | xargs grep -B 1 R_WriteConsole
./src/library/grDevices/src/devWindows.c-setstatus(msg);
./src/library/grDevices/src/devWindows.c:R_WriteConsole(msg,
strlen(msg));
./src/library/grDevices/src/devWindows.c:R_WriteConsole("\n", 1);
--
./src/main/printutils.c-#endif /* HAVE_VA_COPY */
./src/main/printutils.c:R_WriteConsole(p, strlen(buf));
--
./src/main/printutils.c-slen = strlen(buf);
./src/main/printutils.c:R_WriteConsole(buf, slen);
--
./src/gnuwin32/sys-win32.c- } else
./src/gnuwin32/sys-win32.c: R_WriteConsole(buf,
strlen(buf));
--
./src/gnuwin32/system.c-buf[len] = '\0';
./src/gnuwin32/system.c:R_WriteConsole(buf,
strlen(buf));
--
./src/gnuwin32/system.c-fflush(R_Consolefile);
./src/gnuwin32/system.c:} else R_WriteConsole(s, strlen(s));
Jeff
>
> Martin
>
>> "Jeffrey" == Jeffrey Horner <[EMAIL PROTECTED]>
>> on Fri, 29 Sep 2006 15:22:51 -0500 writes:
>
> Jeffrey> In R-2-4-branch r39548, Rcons_vprintf is called from
> stdout_vfprintf
> Jeffrey> when R_Outputfile is NULL. When called and output is greater
> than
> Jeffrey> R_BUFSIZE, output is truncated to R_BUFSIZE. Here's a one-line
> fix:
>
> Jeffrey> Index: src/main/printutils.c
> Jeffrey>
> ===
> Jeffrey> --- src/main/printutils.c (revision 39548)
> Jeffrey> +++ src/main/printutils.c (working copy)
> Jeffrey> @@ -638,7 +638,7 @@
> Jeffrey> res = R_BUFSIZE;
> Jeffrey> }
> Jeffrey> #endif /* HAVE_VA_COPY */
> Jeffrey> -R_WriteConsole(p, strlen(buf));
> Jeffrey> +R_WriteConsole(p, strlen(p));
> Jeffrey> #ifdef HAVE_VA_COPY
> Jeffrey> if(usedRalloc) vmaxset(vmax);
> Jeffrey> if(usedVasprintf) free(p);
>
>
> Jeffrey> Jeff
> Jeffrey> --
> Jeffrey> http://biostat.mc.vanderbilt.edu/JeffreyHorner
>
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] developing a package with a name space
Hello - I'm currently maintaining an R package that uses a name space, and am also starting a new R package that will use a name space. According the the R News June 2003 issue, "Adding a name space to a package may complicate debugging code ... it is a good idea not to add a name space to a package until it is completely debugged, and to remove the name space if further debugging is needed ... other alternatives are being explored ... ". Is renaming/removing the NAMESPACE file still the favored approach when developing and debugging code for an R package? I suppose the alternative I have in mind is something like sourcing an R file, and using assignInNamespace(), may be more trouble than it is worth. I am doing this development using ESS by the way. Thanks for any guidance! Erik Iverson __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] developing a package with a name space
On 10/3/2006 2:22 PM, Erik Iverson wrote: > Hello - > > I'm currently maintaining an R package that uses a name space, and am > also starting a new R package that will use a name space. > > According the the R News June 2003 issue, "Adding a name space to a > package may complicate debugging code ... it is a good idea not to add a > name space to a package until it is completely debugged, and to remove > the name space if further debugging is needed ... other alternatives are > being explored ... ". > > Is renaming/removing the NAMESPACE file still the favored approach when > developing and debugging code for an R package? > > I suppose the alternative I have in mind is something like sourcing an R > file, and using assignInNamespace(), may be more trouble than it is worth. > > I am doing this development using ESS by the way. > It depends on the type of debugging you're doing. The reason for that suggestion is that usually when you edit a new function, it will live in the global environment, rather than the namespace. This means it won't see objects in the namespace, and they'll see a local copy before they see it. You can make it see things there by setting its environment to be the namespace. I always forget the syntax for that, so I usually do something like environment(newfn) <- environment(someexportedfn) Note that if you use fix(), the environment is automatically preserved, but you'll still create your new copy in the global environment. To let other functions see it, you need to use assignInNamespace(). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in warning() for condition objects (PR#9274)
Full_Name: David Hinds
Version: 2.4.0
OS: Windows XP
Submission from: (NULL) (64.168.232.238)
A (maybe naive) use of tryCatch to trap errors and report as warnings does not
work, i.e.:
x <- tryCatch(lm(xyzzy), error=warning)
In src/library/base/R/stop.R, the warning() function contains the following
code, for handling condition objects:
withRestarts({
.Internal(.signalCondition(cond, message, call))
.Internal(.dfltStop(message, call))
}, muffleWarning = function() NULL)
So all conditions result in calling .dfltStop(). It would seem more useful
and/or consistent for warning() to call .dfltWarn(), or in the alternative, to
choose between .dfltStop and .dfltWarn based on the class of the condition
object.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Display problem with named raw vectors
Hi,
I found that displaying a raw vector with long names is not
as pretty as for other types of named vectors:
> r <- charToRaw("Mz")
> r
[1] 4d 7a
> names(r) <- c("M", "zz")
> r
M zz
4d 7a
The names and the values are not aligned :-(
> i <- as.integer(r)
> i
[1] 77 122
> names(i) <- c("M", "zz")
> i
M zz
77122
Much better :-)
(Note that the names were lost during coercion... surprising
but documented.)
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
