Re: [Rd] Fix for bug in arima function
The bug repository is like an elephant: It doesn't forget, but the gestation period is long. In the present case, it is clear that something is not right, but someone needs to have sufficient recall and insight to check that your proposed fix is not unfixing a deliberate change. We should get to it eventually. (For some value of "we" not including "me"...) -pd On 20 Apr 2015, at 18:34 , Patrick Perry wrote: > There is currently a bug in the arima function. Namely, for arima models with > differencing or seasonal differencing, the innovation variance estimator uses > the wrong denominator whenever xreg is non-null. This is the case, for > example, when fitting an ARIMA(p,1,q) model with a drift term (common in > financial applications). I reported the bug (and a fix) at > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16278 , but my report > may have fallen through the cracks due to the timing around the 3.2.0 release. > > The bug was introduced in the patch displayed here: > > https://github.com/wch/r-source/commit/32f633885a903bc422537dc426644f743cc645e0 > > The fix is very simple: > > https://github.com/patperry/r-source/commit/c1701c05ad91d5631eef196c2007ad9897b01f85 > > I’ve posted a script that demonstrates the bug at > > https://gist.github.com/patperry/90a388b056e09cf6a51b > > Please let me know if there’s anything I can do to help get this fix > incorporated. > > > -- > Patrick Perry > Assistant Professor > Stern School of Business > New York University > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug 15899 - Omitted 'extern' on 'R_running_as_main_program' after refactor can cause linker errors for applications embedding R
Is there any plans for addressing the regression... https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15899 in the 3.2.1 release? In the fink project, I had to resort to creating a fixincludes subdirectory containg a local copy of the offending Rinterface.h header with the missing extern on the declaration of R_running_as_main_program restored in order to suppress duplicate symbols during the rstudio build... https://support.rstudio.com/hc/communities/public/questions/203671967-duplicate-R-running-as-main-program-break-linkage-of-rstudio-desktop-0-98-1103-against-R-3-2-0?locale=en-us [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] shlib problems with Intel compiler
Hi, I'm encountering trouble compiling caTools_1.17.1.tar.gz and e1071_1.6-4.tar.gz on a Linux system using the Intel compiler suite. 14 other packages I generally use installed without any trouble. I notice both of these trouble packages have a C++ component, so I wonder if that might be the issue. Below, there's information on my platform, compiler, and some diagnostic output showing the errors. Advice appreciated! Thanks, Andy Intel compiler suite: icc (ICC) 14.0.2 20140120 sessionInfo() reports: R version 3.1.3 (2015-03-09) Platform: x86_64-unknown-linux-gnu (64-bit) Running under: Red Hat Enterprise Linux Server release 6.5 (Santiago) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_3.1.3 Abbreviated versions of the output from R CMD INSTALL: For caTools: * installing to library ‘/scratch3/BMC/co2/lib/R-3.1/x86_64-unknown-linux-gnu’ * installing *source* package ‘caTools’ ... ** package ‘caTools’ successfully unpacked and MD5 sums checked ** libs icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG -I/usr/local/include -fpic -g -O3 -fp-model precise -c Gif2R.cpp -o Gif2R.o icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG -I/usr/local/include -fpic -g -O3 -fp-model precise -c GifTools.cpp -o GifTools.o icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG -I/usr/local/include-fpic -g -O3 -wd188 -ip -fp-model precise -c runfunc.c -o runfunc.o icpc -L/usr/local/lib64 -o caTools.so Gif2R.o GifTools.o runfunc.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' Gif2R.o: In function `imwritegif': /tmp/RtmpEfnBsm/R.INSTALL17c3a7327d4fb/caTools/src/Gif2R.cpp:19: undefined reference to `R_chk_calloc' /tmp/RtmpEfnBsm/R.INSTALL17c3a7327d4fb/caTools/src/Gif2R.cpp:23: undefined reference to `R_chk_free' ... (many more R_* undefined references) For e1071: * installing to library ‘/scratch3/BMC/co2/lib/R-3.1/x86_64-unknown-linux-gnu’ * installing *source* package ‘e1071’ ... ** package ‘e1071’ successfully unpacked and MD5 sums checked checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether icpc accepts -g... yes ** libs icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG -I/usr/local/include-fpic -g -O3 -wd188 -ip -fp-model precise -c Rsvm.c -o Rsvm.o icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG -I/usr/local/include-fpic -g -O3 -wd188 -ip -fp-model precise -c cmeans.c -o cmeans.o icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG -I/usr/local/include-fpic -g -O3 -wd188 -ip -fp-model precise -c cshell.c -o cshell.o icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG -I/usr/local/include-fpic -g -O3 -wd188 -ip -fp-model precise -c floyd.c -o floyd.o icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG -I/usr/local/include -fpic -g -O3 -fp-model precise -c svm.cpp -o svm.o icpc -L/usr/local/lib64 -o e1071.so Rsvm.o cmeans.o cshell.o floyd.o svm.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' Rsvm.o: In function `do_cross_validation': /tmp/Rtmp9h7iYE/R.INSTALL1d9615a42180e/e1071/src/Rsvm.c:91: undefined reference to `GetRNGstate' /tmp/Rtmp9h7iYE/R.INSTALL1d9615a42180e/e1071/src/Rsvm.c:94: undefined reference to `unif_rand' /tmp/Rtmp9h7iYE/R.INSTALL1d9615a42180e/e1071/src/Rsvm.c:106: undefined reference to `PutRNGstate' ... (many more undefined references) -- Andy Jacobson andy.jacob...@noaa.gov NOAA Earth System Research Lab Global Monitoring Division 325 Broadway R/GMD1 Boulder, Colorado 80305 303/578-2237 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in src/scripts/config
Was writing a short R script to modify compile flags and saw this typo: Index: config === --- config (revision 68217) +++ config (working copy) @@ -61,7 +61,7 @@ CXX1X C++ compiler command for C++11 code CXX1XSTD flag used to enable C++11 support CXX1XFLAGSC++11 compiler flags - CXX1XXPICFLAGS + CXX1XPICFLAGS special flags for compiling C++11 code to be turned into a shared library DYLIB_EXT file extension (including '.') for dynamic libraries -- http://www.keittlab.org/ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typo in src/scripts/config
Fixed in R-patched and R-devel. Thanks. (In case it wasn't obvious, the typo was in the usage output; there was no actual malfunction.) -pd > On 21 Apr 2015, at 19:53 , Tim Keitt wrote: > > Was writing a short R script to modify compile flags and saw this typo: > > Index: config > === > --- config (revision 68217) > +++ config (working copy) > @@ -61,7 +61,7 @@ > CXX1X C++ compiler command for C++11 code > CXX1XSTD flag used to enable C++11 support > CXX1XFLAGSC++11 compiler flags > - CXX1XXPICFLAGS > + CXX1XPICFLAGS > special flags for compiling C++11 code to be turned into > a shared library > DYLIB_EXT file extension (including '.') for dynamic libraries > > -- > http://www.keittlab.org/ > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RObjectTables freezes in R 3.2.0 RC on 32bit systems
Looks like names() never worked on object tables on any platfom; the failure was just more obvious on 32-bit systems than on 64-bit ones. This is now fixed in R-devel and R-patched. Best, luke On Wed, 15 Apr 2015, Jeroen Ooms wrote: On Tue, Apr 14, 2015 at 6:29 PM, Jeroen Ooms wrote: Things work as expected up till dbread(), but once the object-table is attached, R freezes on 32bit whereas it works as expected on 64bit. Debugging this some more, it looks like the freeze appears at the very end of the attach function, when it calls length(names(value)) on the newly created object-tables environment. At this stage, calling ls(value) gives the expected output, but calling names(value) or length(value) triggers the freeze. The NEWS file does mention that R 3.2.0 introduces some changes to names(env) internals. Could it be that this somehow conflicts with the object tables hooks? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] alternate licensing for package data?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does anyone have speculations about the implications of the GPL for data included in a package, or more generally for restricting use of data? The specific use case is that I have a package which is otherwise GPL (version unspecified at present). There are various data sets included, but they are all essentially in the public domain. I'm thinking about including another data set, but the original author of that data might like to impose some reasonable restrictions (e.g. please don't use in an academic publication without explicit permission ...) Would such rules be expected to be compatible with CRAN rules? Will having the package be "GPL except for file XXX, see LICENSE" mess things up horribly? I can of course make the data available for download and include a link, and/or make a special package that contains only these data, but it would seem to be more convenient for end users, and more future-proof, to put everything in one place. I know I will eventually need to take this up with CRAN, but I'm looking for reasonably informed opinions/suggestions ... cheers Ben Bolker -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJVNtvYAAoJEOCV5YRblxUHh90H/0GgmeF1wzRmPYndxYRWXegv bKlkmibRBvUwfBsv1BzPmiQ08Hs+eZp4NnP6Wh7TigfAZlvkl8hq0rHr/RWzY+XT Fo8xkeuydVk3vxSdunHpl10gnGDjb845MSigL+W7X587xAY5wmB9+QzuudNaIL2U URR+jp3OG0Np1mJQX/7lVMi34L71cT7jZKTaBiFLzYJB1x0RvE+xXqGoj+NcNVqA zYjUWyYCzPfCJJVCI+DsbLUgnWKTYYsWEq1lWabE2HKfqio2pInbQSOtdw6s3VX/ kwvQU4WOhJYHedmzNNsWBnpm04gbIrK71i9FN7Iw5kNQjbsqAN7YPZ6rD1GsjGE= =Gos/ -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
