2

I am using R 3.2.1 for Mac OS X and seem to have run into incorrect behavior in xts subsetting. In brief, subsetting monthly data give a result that is 1 month lagged from what it should be. Here is a simple example that is similar to an analysis of paleotemperature I am doing:

First I will make some test data for the example:

xts.test <- xts(rnorm(440*12, mean=0, sd=10),order.by=timeBasedSeq(155001/1989))

This produces a correct xts file AFAICT. Here is the first year of 12 months.

head(xts.test, 12L)

               [,1]
Jan 1550 -6.9301845  
Feb 1550 12.1581413  
Mar 1550  3.9688139  
Apr 1550  3.9540268  
May 1550  9.8200923  
Jun 1550 -4.2090998  
Jul 1550  7.5950340  
Aug 1550 -6.5967389  
Sep 1550 -0.6736532  
Oct 1550  6.4939221  
Nov 1550  4.3916465  
Dec 1550 19.8800872  

However, when I try to subset this by selecting for a single year, I get the following:

xts.test["1550"]

               [,1]
Feb 1550 12.1581413  
Mar 1550  3.9688139  
Apr 1550  3.9540268  
May 1550  9.8200923  
Jun 1550 -4.2090998  
Jul 1550  7.5950340  
Aug 1550 -6.5967389  
Sep 1550 -0.6736532  
Oct 1550  6.4939221  
Nov 1550  4.3916465  
Dec 1550 19.8800872  
Jan 1551 -2.9549224  

That is, instead of the correct Jan-Dec 1550, I get Feb 1550 through Jan 1551

I get a similar lag when I try to subset by selecting months of a year. c(2, 3,4,5,6,7) get me April through September instead of March through August.

Any thoughts here?

  • Would you please set a seed with `set.seed` and desribe all the packages you have loaded by `library` or `require`? That would help to reproduce the behavior. – PavoDive Aug 03 '15 at 00:53

1 Answers1

4

This is a bug that has been fixed in the most recent development version on GitHub.

R> require(xts)
R> xts.test <- xts(rnorm(440*12, mean=0, sd=10),order.by=timeBasedSeq(155001/1989))
R> packageVersion("xts")
[1] ‘0.9.7’
R> str(xts.test)  # notice TZ is not set
An ‘xts’ object on Jan 1550/Dec 1989 containing:
  Data: num [1:5280, 1] -8.11 -7.65 2.07 -3.29 17.03 ...
  Indexed by objects of class: [yearmon] TZ: 
  xts Attributes:  
 NULL

Notice that TZ is not set above, but it's set in the new version below.

R> packageVersion("xts")
[1] ‘0.9.8’
R> str(xts.test)  # notice TZ is set
An ‘xts’ object on Jan 1550/Dec 1989 containing:
  Data: num [1:5280, 1] 0.357 12.318 24.291 22.181 6.123 ...
  Indexed by objects of class: [yearmon] TZ: UTC
  xts Attributes:  
 NULL
Joshua Ulrich
  • 173,410
  • 32
  • 338
  • 418
  • Thanks. Hopefully it will fix apply.yearly and related methods too. Can you tell me when this will be available as an installable package? – Michael Barton Aug 03 '15 at 05:08
  • FWIW, I tried to install the current dev version of xts using R devtools. Compiling failed, however, because it has a call (unneeded??) to gfortran 4.8. – Michael Barton Aug 06 '15 at 15:50
  • @MichaelBarton: it's needed. I assume you're on Windows; do you have [Rtools](https://cran.r-project.org/bin/windows/Rtools/) installed? – Joshua Ulrich Aug 06 '15 at 17:11
  • I'm on a Mac. It's the first time an R package has called for gfortran. – Michael Barton Aug 07 '15 at 19:26
  • @MichaelBarton: I guess it's the first R package you've built from source that includes Fortran code... – Joshua Ulrich Aug 07 '15 at 19:56
  • Maybe so. But I DO have gfortran on my system. Just to be sure, I just updated it. The problem may be that the configuration or make code has hard coded a link to gfortran-4.8. I have a later version. – Michael Barton Aug 07 '15 at 22:18
  • @MichaelBarton: It could be that, or it could be something else that's specific to OS X. Check the [OS X appendix](https://cran.r-project.org/doc/manuals/R-admin.html#OS-X) to the R Installation and Administration manual for hints. I don't use OS X myself, nor do I have access to one, so I'm afraid I can't help more directly. – Joshua Ulrich Aug 07 '15 at 23:41
  • Sorry if I was not being clear. Either configuration or make makes a hard-coded call to a specific version of gfortran, an older one (gfortran 4.8). Here is the error: --- gfortran-4.8 -fPIC -g -O2 -c period.max.f -o period.max.o make: gfortran-4.8: No such file or directory --- I have a newer version (gfortran 5.1). I suspect that it does not matter which version I have as long as it is sufficiently new to have whatever functions are called in compiling xts. But the current code only looks for version 4.8 AFAICT. – Michael Barton Aug 08 '15 at 22:57
  • @MichaelBarton: xts does not make any decisions regarding C or Fortran compilers. The "current code" that "only looks for version 4.8" is R itself, not xts. – Joshua Ulrich Aug 08 '15 at 23:43
  • Thanks for the clarification – Michael Barton Aug 09 '15 at 04:27
  • 1
    I installed gfortran 4.8 over my later version. xts still would not compile. So I had to make a symlink named gfortran-4.8 to /usr/local/bin/gfortran. Then xts compiled without issue. Unfortunately, when I loaded the newest xts (v. 0.9.874), it still has the same problem that I reported initially. So this does not seem to be fixed. – Michael Barton Aug 09 '15 at 05:04