Як об’єднати дані щомісяця, дня та тижня?


11

Google Trends повертає щотижневі дані, тому мені доведеться знайти спосіб їх об'єднання зі своїми щоденними / щомісячними даними.

Що я зробив досі, це перебити кожну серію на щоденні дані, наприклад:

від:

2013-03-03 - 2013-03-09 37

до:

2013-03-03 37 2013-03-04 37 2013-03-05 37 2013-03-06 37 2013-03-07 37 2013-03-08 37 2013-03-09 37

Але це додає великої складності моїй проблемі. Я намагався передбачити пошук Google за значеннями останніх 6 місяців або 6 значеннями в місячних даних. Щоденні дані означатимуть роботу за 180 минулими значеннями. (У мене є 10 років даних, тому 120 даних у щомісячних даних / 500+ у даних за тиждень / 3500+ у щоденних даних)

Іншим підходом було б "об'єднання" щоденних даних у дані щотижня / щомісяця. Але з цього процесу виникають деякі питання. Деякі дані можна усереднювати, оскільки їх сума щось являє. Наприклад, кількість опадів, кількість опадів за даний тиждень, буде сумою сум за кожен день, що складає тижні.

У моєму випадку я маю справу з цінами, фінансовими ставками та іншими речами. Щодо цін, у моєму полі звичайно враховувати обмін, який обмінюються, тому дані за тиждень були б середньозваженими. Щодо фінансових ставок, то трохи складніше, деякі формули використовуються для побудови тижневих ставок із денних. Для інших речей я не знаю основних властивостей. Я думаю, що ці властивості важливі, щоб уникнути безглуздих показників (наприклад, середній показник ставок для наречених був би безглуздим).

Отже три питання:

Як для відомих і невідомих властивостей я повинен переходити від щоденних до щотижневих / щомісячних даних?

Я відчуваю, що розбивати дані щотижня / щомісяця на щоденні дані, як я це зробив, є дещо неправильним, оскільки я ввожу кількості, які не мають сенсу в реальному житті. Тож майже те саме питання:

Як для відомих і невідомих властивостей я повинен переходити від даних щотижня / щомісяця до щоденних?

І останнє, але не менш важливе: якщо дано два часові ряди з різними кроками часу, що краще: використання найменшого чи найбільшого часового кроку? Я думаю, що це компроміс між кількістю даних та складністю моделі, але я не бачу жодного сильного аргументу для вибору між цими варіантами.

Редагувати: якщо ви знаєте інструмент (в R Python навіть Excel), щоб зробити це легко, було б дуже вдячно.


для пітона стандартним інструментом є панди. Він був спеціально розроблений для роботи з часовими журналами фінансових даних. pandas
timeseries

Хочете трохи розширити, що ви маєте на увазі під "невідомим майном"?
TheGrimmScientist

Відповіді:


8

якщо дано два часові ряди з різними часовими кроками, що краще: Використання найменшого чи найбільшого часового кроку?

Для аналізу часових виписок слід зробити і те, і інше: досягти максимальної деталізації із щоденним набором даних, а також повторити аналіз із щомісячним набором даних. З набором даних на місяць ви маєте 120 точок даних, що достатньо для отримання моделі часових випусків навіть з урахуванням сезонності ваших даних.

Як для відомих і невідомих властивостей я повинен переходити від щоденних до щотижневих / щомісячних даних?

Щоб отримати дані щотижня або щомісяця з щоденних даних, ви можете використовувати функції згладжування. Для фінансових даних ви можете скористатися ковзними середніми або експоненціальними згладжуваннями, але якщо вони не працюють для ваших даних, ви можете використовувати функцію згладжування сплайну "smooth.spline" в R: https://stat.ethz.ch/R -manual / R-patched / library / stats / html / smooth.spline.html

Повернута модель матиме менше шуму, ніж початковий щоденний набір даних, і ви можете отримати значення для бажаних часових точок. Нарешті, ці точки даних можуть бути використані у вашому аналізі часових журналів.

Як для відомих і невідомих властивостей я повинен переходити від даних щотижня / щомісяця до щоденних?

Для отримання щоденних даних, коли у вас є дані щомісяця або щотижня, ви можете використовувати інтерполяцію. Спочатку слід знайти рівняння для опису даних. Для цього слід нанести дані (наприклад, ціна з часом). Коли вам відомі фактори, на це рівняння повинні впливати ці фактори. Коли фактори невідомі, ви можете використовувати рівняння найкращого пристосування. Найпростішою буде лінійна функція або кусочно лінійна функція, але для фінансових даних це не спрацює добре. У цьому випадку слід розглянути куполоподібну інтерполяцію сплайну. Це посилання детальніше описує можливі функції інтерполяції: http://people.math.gatech.edu/~meyer/MA6635/chap2.pdf .

У R є метод здійснення інтерполяції даних часових журналів. Тут ви створили вектор із сказаними тижневими значеннями та NA в проміжках для денних значень, а потім скористаєтесь функцією "interpNA", щоб отримати інтерпольовані значення для NA. Однак ця функція використовує функцію "приблизно" для отримання інтерпольованих значень, яка застосовує або лінійну, або постійну інтерполяцію. Щоб виконати кубічну сплайновану інтерполяцію в R, замість цього слід використовувати функцію "splinefun".

Що слід пам’ятати, це те, що моделі тимчасових виробництв зазвичай роблять середнє значення для прогнозування майбутніх значень, незалежно від того, чи дивитесь ви експоненціальні згладжування або методи авторегресивного інтегрального пересувного середнього (ARIMA) серед інших. Таким чином, модель тимчасових журналів для прогнозування денних значень може бути не найкращим вибором, але щотижневі або щомісячні моделі можуть бути кращими.


Здається, це практична відповідь. Не впевнений, чи це стосується фінансових часових рядів через арбітраж.
lcrmorin

Я думаю, що відповіді на ваші запитання все ще справедливі. Для моделі часових журналів ви можете подивитися моделі ARCH (Авторегресивна умовна гетерокедастичність).
gchaks

коли ви інтерполюєте, використовуючи, наприклад, кубічний сплайн, у фінансових часових рядах, чи не введете ви передумови вперед? я думаю, це може бути особливо важливим, якщо впроваджувати для моделі машинного навчання?
цандо

5

Я не є експертом у цій галузі, але вважаю, що ваше питання стосується сукупності часових рядів та їх дезагрегації . Якщо це так, ось деякі, сподіваємось, відповідні ресурси, які можуть бути корисними для вирішення вашої проблеми (перші п’ять пунктів є головними, але репрезентативними, а останні два - додатковими):


2

Це не буде дуже задоволеною відповіддю, але ось моя думка ...

Як для відомих і невідомих властивостей я повинен переходити від щоденних до щотижневих / щомісячних даних?

Як для відомих і невідомих властивостей я повинен переходити від даних щотижня / щомісяця до щоденних?

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

Як ви нагадали:

(середній показник фіянських ставок був би безглуздим, наприклад)

Не існує єдиного перетворення, яке було б доречним у всіх випадках, незалежно від того, чи є властивості / значення відомими або невідомими. Навіть з відомими властивостями вам, ймовірно, знадобиться унікальна трансформація для кожного типу: середня, медіана, режим, хв, макс, булева тощо.

якщо дано два часові ряди з різними часовими кроками, що краще: Використання найменшого чи найбільшого часового кроку?

По можливості намагайтеся зберегти повну деталізацію найменшого можливого кроку. Якщо припустити, що ви знаєте, як трансформувати значення, ви завжди зможете виконувати етапи (наприклад, день у місяць, місяць у рік) ... але вам не обов’язково вдасться реконструювати менші кроки з більших кроків після втрати перетворення .


2

Як для відомих і невідомих властивостей я повинен переходити від щоденних до щотижневих / щомісячних даних?

Агрегація.

Наприклад, у вас є кількість часу, коли люди щодня шукали віджети. Додайте підсумки за місяць, щоб отримати підсумки за місяць. Мені потрібно побачити більше конкретних даних про фактичні дані, зібрані при кожній деталізації, щоб отримати більш повну версію.

Як для відомих і невідомих властивостей я повинен переходити від даних щотижня / щомісяця до щоденних?

Ви не можете.

У фізиці порівнянна ідея - частота Найкіста . Загальна думка полягає в тому, що ви не можете додати більше інформації, ніж те, що ви вже маєте у своїх даних, не вводячи більше даних. Враховуючи лише той день, коли хтось провів запит, як ви можете сказати, в який час доби цей запит був запущений? Можливо, ви зможете зробити деякі умовиводи, але єдиний спосіб відповісти на питання - це прямо чи опосередковано вносити в систему більше інформації. Ви можете зробити обґрунтовані здогадки про щоденний стан щомісячних змінних (як згадується gchaks, інтерполяція), але ваші дані все ще є щомісячно щомісячними даними, розтягнутими на вигляд щодня.

Якщо дано два часові ряди з різними часовими кроками, що краще: Використання найменшого чи найбільшого часового кроку?

Це повністю залежить від того, на що ви намагаєтесь відповісти.

Менша зернистість буде більш чутливою до шуму та інших аномалій. Lager деталізація зможе відповідати на питання більш впевнено, але втратить частину корисності. Наприклад, якщо ви намагаєтеся побачити, коли люди починають шукати місця для вихідних, які планують знати, коли розпочати маркетингові кампанії для нового нічного клубу, вам потрібно буде переглянути щоденні дані, якщо не менше. Якщо ви дивитесь на загальну тенденцію нічних клубів, щоб визначити, у кого ви хочете інвестувати, то, щомісяця, мабуть, буде краще.


2

Можливість агрегувати дані на основі сегментів дати - це торт із використанням програмного забезпечення Tableau. Ви просто підключите свої дані до інструменту, а потім зможете перетягнути і метрику, і параметри дати на простір тіла звіту. Tableau миттєво збиває сукупні візуалізації та / або деталізовані таблиці даних на ходу. Ви можете групувати / підсумовувати рік, квартал, місяць, тиждень, день, годину тощо (стандартний, вбудований, з функцій, що пропонуються інструментом)

Крім того, якщо ви хочете включити додаткові дані пізніше (які я вважаю, що ви мали на увазі під "невідомими властивостями"), ви можете імпортувати інший набір даних і легко додати його до першого, якщо він також пропонує дати.

Я рекомендую перевірити безкоштовну версію, яку, на мою думку, називають Tableau Public.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.