printing an xts object

Question

I am trying to create an xts object of this S&P500 sample. This is the code I am using:

sp500 <- read.csv2("SP500.csv",
               stringsAsFactors = F,
               header = T,
               sep = ",",
               na.strings = ".")
sp500$DATE <- as.Date(sp500$DATE)
sp500$SP500 <- as.numeric(sp500$SP500)
library(xts)
sp500idx <- xts(sp500$SP500, order.by = as.Date(sp500$DATE))

When I check str(sp500idx) this appears to have worked. Yet when I try to print the new object by simply typing sp500idx I get the following:

!> sp500idx
            m.c.seq.row..seq.n...seq.col..drop...FALSE.
 2014-03-10                                     1877.17
 2014-03-11                                     1867.63
 2014-03-12                                     1868.20
 2014-03-13                                     1846.34
 2014-03-14                                     1841.13
 2014-03-17                                     1858.83
 2014-03-18                                     1872.25
 2014-03-19                                     1860.77
 2014-03-20                                     1872.01
 2014-03-21                                     1866.52
        ...
 2014-07-15                                     1973.28
 2014-07-16                                     1981.57
 2014-07-17                                     1958.12
 2014-07-18                                     1978.22
 2014-07-21                                     1973.63
 2014-07-22                                     1983.53
 2014-07-23                                     1987.01
 2014-07-24                                     1987.98
 2014-07-25                                     1978.34
 2014-07-28                                     1978.91

What does the first line in this output mean, i.e.

m.c.seq.row..seq.n...seq.col..drop...FALSE.

I have a feeling that it has to do with the number of observations in the xts object. Thanks for your help!

Answer 1

I can't reproduce that but in any case the way to do this is shown below.

To make this self contained we will generate the input file in the Note at the end. Then read it in using read.csv.zoo and convert that to xts.

library(xts)

sp500 <- "SP500.csv" |> read.csv.zoo(drop = FALSE) |> as.xts()

sp500
##              SP500
## 2014-03-10 1877.17
## 2014-03-11 1867.63
## 2014-03-12 1868.20

class(sp500)
## [1] "xts" "zoo"

is.numeric(sp500)
## [1] TRUE

class(time(sp500))
## [1] "Date"

Note

Lines <- "DATE,SP500
2014-03-10,1877.17
2014-03-11,1867.63
2014-03-12,1868.20
"

cat(Lines, file = "SP500.csv")

Comment

Regarding your comment |> says insert the left hand side of the pipe into the first argument of the function call on the right hand side of the pipe and run it so the pipeline shown is the same as as.xts(read.csv.zoo(sp500, drop = FALSE)) but flows from left to right and avoids harder to read nested parentheses .

For further info on any package go to, for example, https://cran.r-project.org/package=zoo and review the vignettes, if any, the reference manual and any other links there.

To get further info on a command look at its help page, for example, ?zoo, ?xts, ?read.csv.zoo, etc.  To see examples look at the bottom of that command's help page. Issuing a command at the R console without the () will show its R source code, e.g. read.csv.zoo .

read.csv.zoo is a simple wrapper of read.zoo (based on read.csv instead of read.table) and there is an entire vignette on read.zoo .

Answer 2

As the maintainer of xts points out here, the issue is that in its present version 0.13.2, xts makes up some column name for the numeric vector sp500$SP500. The behaviour can be avoided by calling sp500["SP500"] instead. So, the immediate solution to the problem I posted is:

sp500 <- read.csv2("SP500.csv",
                   stringsAsFactors = F,
                   header = T,
                   sep = ",",
                   na.strings = ".")
sp500$DATE <- as.Date(sp500$DATE)
sp500$SP500 <- as.numeric(sp500$SP500)
sp500idx <- xts(sp500["SP500"], order.by = as.Date(sp500$DATE))

It goes without saying that the solution @GGrothendieck provided is much more elegant.

Thanks to @GGrothendieck for his insights and to @RuiBaradas for suggesting to contact the maintainer.