Ограничение размера XTS

В последнее время я работаю с большими наборами данных (более 400 тысяч строк). До сих пор я использовал формат XTS, который отлично работал для «небольших» наборов данных из нескольких десятых тысяч элементов.

Теперь, когда проект растет, R просто падает при извлечении данных для базы данных и помещении их в XTS.

Насколько я понимаю, R должен иметь векторы размером до 2 ^ 32-1 элемента (или 2 ^ 64-1 в зависимости от версии). Следовательно, я пришел к выводу, что у XTS могут быть некоторые ограничения, но я не смог найти ответ в документе. (возможно, я был немного самоуверен в своем понимании теоретически возможного размера вектора).

Подводя итог, я хотел бы знать, если:

  1. XTS действительно имеет ограничение по размеру
  2. Как вы думаете, какой самый разумный способ обработки больших временных рядов? (Я думал о разделении анализа на несколько небольших наборов данных).
  3. Я не получаю сообщения об ошибке, R просто автоматически отключается. Это известное поведение?

РЕШЕНИЕ

  1. То же, что и R, и это зависит от типа используемой памяти (64 бита, 32 бита). В любом случае он очень большой.
  2. Разделение данных действительно хорошая идея, но в этом нет необходимости.
  3. Эта проблема возникла из-за ошибки в R 2.11.0, которая была решена в R 2.11.1. Возникла проблема с вектором длинных дат (здесь индексы XTS).

r time time-series xts
person SRKX    schedule 29.06.2010    source источник
comment
R 3.0.0 позволяет использовать векторы с › 2^32 - 1 элементами. Официальный релиз запланирован на апрель, а пока попробуйте версию R для r-devel.   -  person G. Grothendieck    schedule 02.01.2013

Ответы (1)


arrow_upward
5
arrow_downward

Что касается ваших двух вопросов, мои 0,02 доллара:

  1. Да, для R-векторов существует ограничение в 2^32-1 элемента. Это происходит из-за логики индексации, и, как сообщается, она находится «глубоко внутри» в R, поэтому вряд ли ее скоро заменят (поскольку это повлияет на так много существующего кода). Google список r-devel для деталей; это появилось раньше. Пакет xts не накладывает дополнительных ограничений.

  2. Да, разделение вещей на управляемые куски — самый разумный подход. Раньше я делал это с большими наборами данных, когда работал исключительно с 32-разрядными версиями R. Теперь я использую 64-разрядную версию R, и у меня больше нет этой проблемы (и/или я сохраняю свои наборы данных в порядке),

Есть некоторые подходы «недостаточно памяти», но я бы сначала попытался переосмыслить проблему и подтвердить, что вам действительно нужны все 400 тыс. строк одновременно.

person Dirk Eddelbuettel    schedule 29.06.2010
comment
Ну, дело в том, что я применяю некоторые индикаторы к набору данных. В основном я должен найти лучшие параметры для этих индикаторов. Так что разбиение по частям не очень хорошо для меня, потому что это делает мой анализ прерывистым. Что я мог бы сделать, так это рассматривать только кадр и непрерывно перемещать кадр данных. (например, 1...10, 2...11,3....12 и каждый раз запрашивать базу данных). - person SRKX; 29.06.2010
comment
На самом деле я заметил, что если я выполняю вычисления и не отображаю результаты в консоли R, R не падает. Это проблематично только при отображении данных каким-либо образом. Хорошо знать. Любая идея, почему это так? - person SRKX; 29.06.2010
comment
@JSMaga: возможно, функция print/plot не может обрабатывать такое количество строк. Вы все равно не сможете прочитать так много, поэтому лучше сначала обобщить и отображать только то, что вам нужно. - person Richie Cotton; 29.06.2010
comment
@ Ричи Кутон: действительно. Даже попытка отобразить его в R приводит к сбою. Это должно дать мне ошибку, хотя. Вместо того, чтобы рухнуть... - person SRKX; 30.06.2010
comment
@Richie Cooton: ошибка возникла в самом R. Это было решено в последней версии. Так что print/plot справится с таким количеством очков... - person SRKX; 11.07.2010