Справиться с чрезмерным количеством нулей - PullRequest
0 голосов
/ 14 ноября 2018
ipdb> np.count_nonzero(test==0) / len(ytrue) * 100                                                                                          
76.44815766923736

У меня есть файл данных, подсчитывающий цены 24000, где я использую их для задачи прогнозирования временных рядов.Вместо того, чтобы пытаться предсказать цену, я попытался предсказать log-return, т.е. log(P_t/P_P{t-1}).Я применил журнал возврата по ценам, а также все функции.Прогноз не плохой, но тенденция склонна прогнозировать ноль.Как вы можете видеть выше, ~76% данных являются нулями.

Теперь идея, вероятно, заключается в том, чтобы «искать нулевую оценку: сначала предскажите, будет ли она нулем; если нет, то предскажите значение».

В деталях, как лучше всего справиться с чрезмерным количеством нулей?Как нулевая завышенная оценка может помочь мне с этим?Изначально имейте в виду, что я не вероятностный специалист.

PS Я работаю, пытаясь предсказать лог-доходность, в которой единицами являются «секунды» для исследования высокочастотной торговли.Помните, что это проблема регрессии (а не проблема классификации).

Обновление

enter image description here

Этокартина, вероятно, лучшее предсказание, которое я имею в журнале возврата, то есть log(P_t/P_{t-1}).Хотя это и неплохо, остальные прогнозы имеют тенденцию предсказывать ноль.Как вы можете видеть в приведенном выше вопросе, слишком много нулей.У меня, вероятно, та же проблема с компонентами, что и с журналом возврата функций, т. Е. Если F является определенной функцией, тогда я применяю log(F_t/F_{t-1}).

Вот один деньданные log_return_with_features.pkl , с формой (23369, 30, 161).Извините, но я не могу сказать, какие функции.Поскольку я применяю журнал (F_t / F_ ​​{t-1}) ко всем функциям и цели (то есть цене), то учтите, что я добавил 1e-8 ко всем функциям перед применением операции возврата журнала, чтобы избежать разделенияна 0.

1 Ответ

0 голосов
/ 15 ноября 2018

Хорошо, судя по вашему графику: это характер данных, цена не так часто меняется.

Попробуйте немного сэмплировать исходные данные (возможно, в 5 раз, просто посмотрите на данные), чтобы вы обычно видели движение цены с каждым тактом.Это должно значительно упростить любое моделирование MUCH .

Для подвыборки: я предлагаю вам сделать простую регулярную понижающую выборку во временной области.Таким образом, если у вас есть данные о ценах со вторым разрешением (то есть один ценник каждую секунду), просто возьмите каждую пятую точку данных.Затем действуйте, как вы обычно делаете, в частности, рассчитайте логарифмическое увеличение цены на основе этих данных.Помните, что что бы вы ни делали, оно должно воспроизводиться во время теста.

Если это не подходит для вас по каким-либо причинам, взгляните на что-то, что может работать с несколькими шкалами времени, например WaveNet или Заводной RNN .

...