В связи с тем, что у моего проекта появились доны, считаю важным рассказать о своих успехах за прошедший месяц. Я конкретно упоролась с тестированием коинтеграции на часовом таймфрейме брутфорсом. Давно еще обнаружилась проблема в моем софте: на часовиках появляется очень много «дыр» в данных, из-за чего совместить их «в лоб» друг с другом оказывается не самой лучшей идеей, потому что идеально совпадающих пар в таком случае получается очень мало.
Этой проблемы практически не возникало на дневном таймфрейме. Также это легко решить при тестировании одной пары, но когда речь идет о тысячах или миллионах пар, ребром встает вопрос, а что с этим делать? Первое, что предстояло решить: заполнять пропущенные значения или симметрично удалять «дыры» из второго ряда в паре. Я решила, что удалять данные, — это слишком расточительно, поэтому выбрала первый вариант.
Далее оставался вопрос, каким методом заполнять данные. На выбор было:
- предыдущим не пропущенным значением
- следующим не пропущенным значением
- ближайшим не пропущенным значением
- линейной интерполяцией соседних, не пропущенных значений
- кусочно-кубической сплайн-интерполяцией
- сохраняющей форму кусочно-кубической сплайн-интерполяцией
- модифицированной Акима кубической эрмитовой интерполяцией
Я выбрала самый простой первый вариант. На будущее интересно попробовать линейную интерполяцию и сплайны. Не знаю, насколько они будут лучше. Это на самом деле задача для отдельного исследования. Буду рада, если кто-то поделится своими наработками по этой проблеме.
Еще из особенностей работы алгоритма. Если у нас есть 3 ряда со значениями за даты, например:
[3.01.2023, 4.01.2023, 6.01.2023, 9.01.2023, 10.01.2023]
[3.01.2023, 5.01.2023, 6.01.2023, 9.01.2023, 10.01.2023]
[3.01.2023, 4.01.2023, 6.01.2023, 7.01.2023, 10.01.2023]
то при тестировании первой и второй пары значения будут динамически достроены до массива:
[3.01.2023, 4.01.2023, 5.01.2023, 6.01.2023, 9.01.2023, 10.01.2023]
а при тестировании первой и третьей пары значения будут динамически достроены до массива:
[3.01.2023, 4.01.2023, 6.01.2023, 7.01.2023, 9.01.2023, 10.01.2023]
то есть я пытаюсь по минимуму модифицировать исходные ряды своими «догадками» о пропущенных значениях, чтобы сохранить адекватность статистических тестов на коинтеграцию. Для того, чтобы обеспечить такую аккуратную подстройку, оригинальные массивы остаются без изменений: алгоритмы оперируют динамически «восстановленными» копиями.
Так как у меня шарповый код, еще одной проблемой стала работа со ссылочными типами, для решения которой пришлось реализовать интерфейс ICloneable с поверхностной копией текущего объекта, чтобы предоставить специальному типу возможность возвращения вызывающему коду идентичной копии самого себя.
заполнение выглядит подозрительно: неопределенность заменяется моделью и так же происходит как-бы увеличение торгового времени пары
можно проверить чему соответствует pnl пары — оценке с заполнением или без
если пропуски из-за отсутствия ликвидности, то на практике такое торговать не получится. И такое исследование лишено практического смысла.
Ограничься ликвидными инструментами.
Какие рынки и тикеры исследуешь?
Исследую все тикеры на 7 биржах (MOEX, NYSE, NASDAQ, AMEX, Poloniex, Binance, Kraken).
Для торговли я бы заполнял эти пробелы значениями по которым можно войти в сделку, а для статистики может сгодиться и среднее значение между до и после пробела.
Задача грамотной симуляции торговли — это другой вопрос, который к статистическим тестам имеет мало отношения.
Помню я тоже лет 10 назад искал зависимости в парах на основе скачанных котировок. И также решал проблемы с заполнением пустот. И получал красивые и обнадеживающие результаты. Потом все пришлось выкинуть в корзину, т.к. для практики оказались нужны совершенно другие данные и другие методы анализа.
В любом случае, всякий опыт полезен. Успехов в исследованиях!
имхо сделка это уже прошлое, и повоторить прошлое трудно.
я смотрю только на текущие котировки, сделки только как ориентир по объему и разбросу цен
маленький объем свечки… т.е свеча с маленьким обемом < торгуемой суммы...
должно быть обьем свечи >> торгуемой суммы… торгуемая сумма должна быть 3% от объема свечи максимум
В будущее подглядывание чувствую я.