странное поведение слияния xts

#r #xts

Вопрос:

У меня есть 3 объекта xts, все признаки которых являются объектами «Дата»:

 gt; a  a  1995-01-03 1.76  1995-01-04 1.69  gt; b  b  1995-01-03 1.67  1995-01-04 1.63  gt; c  c  1995-01-03 1.795  1995-01-04 1.690  

Чтобы убедиться, что индексы совпадают:

 gt; index(a) == index(b)  [1] TRUE TRUE  gt; index(a) == index(c)  [1] TRUE TRUE  

Теперь я вижу это странное поведение:

 gt; merge.xts(a,b)  a b  1995-01-03 NA 1.67  1995-01-03 1.76 NA  1995-01-04 NA 1.63  1995-01-04 1.69 NA  

В то время как следующее слияние работает нормально:

 gt; merge.xts(a,c)  a c  1995-01-03 1.76 1.795  1995-01-04 1.69 1.690  

Я не могу понять, что здесь может происходить. Есть идеи?

Обновить:

 gt; dput(a)  structure(c(1.76, 1.69), .indexCLASS = "Date", .indexTZ = "", .CLASS = "xts", class = c("xts",   "zoo"), index = structure(c(789168240, 789254580), tzone = "", tclass = "Date"), .Dim = c(2L,   1L), .Dimnames = list(NULL, "a"))   gt; dput(b)  structure(c(1.67, 1.63), .indexCLASS = "Date", .indexTZ = "", .CLASS = "xts", class = c("xts",   "zoo"), index = c(789109200, 789195600), .Dim = c(2L, 1L), .Dimnames = list(  NULL, "b"))   gt; dput(c)  structure(c(1.795, 1.69), .indexCLASS = "Date", .indexTZ = "", .CLASS = "xts", class = c("xts",   "zoo"), index = c(789109200, 789195600), .Dim = c(2L, 1L), .Dimnames = list(  NULL, "c"))  

Действительно, проблема в том, что индексы не идентичны (как это подтверждено .index(a) == .index(b) ). Преобразование в числовое, затем повторное создание xts и пересчет дат с asDate устранением проблемы.

Эти объекты были созданы с to.daily помощью метода из xts.

Комментарии:

1. Пожалуйста, замените результаты печати a , b , c результатами dput(a) , dput(b) , dput(c) .

2. Я займусь этим … и точка. Спасибо за предысторию.

Ответ №1:

Это, конечно, кажется запутанным, но причина в том, что дата неточна. Все, что происходит в течение календарного дня, является одной и той же «датой».

Где-то, как упоминал Джош, есть тот факт, что ваши данные создаются разными способами/источниками. Я постараюсь придумать лучший способ управления этой изменчивостью, поскольку это не чисто новая проблема. До тех пор:

 index(x) lt;- index(x)   

сделает свое дело. Почему?

Как отмечает Джош, index(x) [no lt;- ] берет базовое time_t представление POSIX и преобразует его в дату (дни, прошедшие с эпохи). Замена исходного индекса через indexlt;- преобразует «Дату» обратно в время POSIX (POSIXct в R, time_t в C)

 t1 lt;- Sys.time()  t2 lt;- Sys.time()   as.Date(t1) == as.Date(t2)  #[1] TRUE   t1 == t2  #[1] FALSE    x1 lt;- xts(1, t1)  x2 lt;- xts(2, t2)    indexClass(x1) lt;- "Date"  indexClass(x2) lt;- "Date"  cbind(x1,x2)  ..1 ..2  2011-10-06 1 NA  2011-10-06 NA 2   .index(cbind(x1,x2))  [1] 1317925443 1317925447  attr(,"tzone")  [1] "America/Chicago"  attr(,"tclass")  [1] "Date"   # ugly, ugly solution  index(x1) lt;- index(x1)  index(x2) lt;- index(x2)  cbind(x1,x2)  ..1 ..2  2011-10-06 1 2  .index(cbind(x1,x2))  [1] 1317877200  

Ответ №2:

Вы не можете использовать index() для проверки того, что индексы одинаковы, потому что он преобразует индекс в то, что указано indexClass() . Используйте .index для получения необработанного числового индекса, тогда вы, скорее всего, обнаружите, что:

 all(.index(a) == .index(b)) # is FALSE  

Вам следует изучить свой источник данных, чтобы понять, что может быть причиной этого. Чтобы быстро исправить ситуацию, сделайте это:

 index(b) lt;- as.Date(index(b))