Comments 5
Мне знакома эта тема. И мне кажется, что вы пытаетесь сделать совсем не то. Вы пытаетесь сделать максимально точное моделирование на истории, а это не имеет практического смысла. Вся точность моделирования убивается шумом.
Зачем, например, считать ликвидацию? Ну, выдало моделирование, что ликвидировало на истории с депозитом 1000. А с 1002 - не ликвидировало. И что дает это знание? Что нужно идти торговать на реальном счете с депозитом 1002? Вообще, ликвидация, это то, к чему при нормальном риск-менеджменте вы даже близко не подойдете.
И зачем просчитывать работу под залог других активов? Везде условия могут быть разными. А есть еще DEX, причем разные варианты... Вы же не пытаетесь просчитать ADL? Только проскальзывание можно заложить (очень примерно и условно), и это отдельная задачка. Вряд ли кто-то ожидал то проскальзывание, которое было 10 октября.
На мой взгляд, бэк-тестинг должен выдать в качестве результатов основные результаты моделирования - просадку, коэффициент шарпа и другие подобные параметры. На основании их становится понятно - может стратегия быть прибыльной или нет. Никакие ликвидации просчитывать не нужно. Можно даже совсем не учитывать размер депозита, считать его бесконечным. А дальше уже на основе этих параметров расчитывать риск-менеджмент. Кстати, при такой постановке задачи, шортовые трейды добавляются достаточно легко, и заголовок статьи становится уже не актуальным :)
С утверждением о том, что если всё упростить, то всё становится легко, трудно не согласиться :)
И эти упрощения правда приходится делать, вопрос — на каком моменте. В своём проекте я представляю себе "стратегию" (то, что у меня представлено интерфейсом Strategy) не как генератор сигналов, а как трейдинговую систему, которая сама и размеры позиций определяет, и риск-менеджментом занимается.
В таком контексте моделирование с "бесконечным депозитом" и без ликвидаций просто не сработало бы. Точнее, оно показало бы только насколько хорошо стратегия определяет точки входа/выхода, но ничего не сказало бы про риск-менеджмент — а в любом реальном применении это всё-такии очень важный фактор. С бесконечным депозитом и без ликвидаций можно просто удваивать размер позиции после каждого проигрыша и рано или поздно выигрывать, но я бы такому трейдинговому боту свои кровные не доверил.
В целом, мне кажется, вопрос упрощать или не упрощать зависит от постановки задачи. Я попытался включить риск-менеджмент в бэктестинг, а про то, хороший это подход или нет — обязательно напишу ещё, когда дойду до демо-трейдинга :)
Такое ощущение, что у Вас смешалось представление о фьючерсных сделках на криптовалютных биржах и традиционных.
Шорт ничем не отличается от лонг. Буквально лишь расчётом того, что является нереалиазованной прибылью сделки, и это надо логично инкапсулировать. Точно так же тело сделки сразу же вычитается из баланса. Может быть, конечно я уже ошибаюсь, но насколько раньше работал, - ни одна биржа не даст вам открыть сделку обеспеченную незафиксированной прибылью.
С ликвидациями при кросс-марже есть тонкости, индивидуальные для бирж, но поддержку идею, что для бэктеста это не особо нужно; стратегия, которая через них "идёт к успеху" может быть и должна быть улучшена.
Пришлось немного посмотреть код, и я разобрался. В принципе в статье иного и не говорилось, речь именно о режиме "маржинальной торговли". Это не фьючерсы, ну точнее, не совсем они, и в общих чертах все устроено примерно так, как автор и описывает. И, конечно, без обсчета ликвидаций там не обойтись даже для симуляции.
Один правда недочет остался, одними комиссиями за сделку тут не обойтись. В режиме маржинальной торговли, за заемные средства ежедневно/ежечасно нужно платить указанный биржей процент, и он немалый, надо отметить. В коде что-то на эту тему ничего не вижу.
Во-первый, спасибо большое за фидбек (и отдельно — за то, что и в код заглянули)! Очень ценно получить мнение человека, который, похоже, имеет побольше опыта в сфере трейдинга, чем я.
Во-вторых, вы правы, на данный момент движок не учитывает процент за заёмные средства; и это точно не то упрощение, которое было бы нормально сделать при том уровне реалистичности, в который я целюсь. К счастью, архитектура легко позволяет это добавить — достаточно внутри движка перед вызовом хука onCandle рассчитывать процент исходя из таймстемпа. Я обязательно добавлю это в самый верх списка бэклога.
По ликвидациям — я согласен, что стратегия не должна работать "через ликвидации" (и поэтому не гонюсь за реалистичным моделированием ADL). Формально можно было бы просто останавливать симуляцию, если случился margin call, но я решил просто логировать это событие и продолжать её; но выше уже писал, почему, на мой взгляд, игнорировать ликвидации было бы критично.
Хочу добавить ещё немного по поводу "странностей" в расчёте залога и той же ликвидации: я ориентировался на конкретную крипто площадку, с API которой собираюсь в дальнейшем работать для демо-трейдинга и в конечном итоге для реального трейдинга. Там используется концепция "единого трейдингового аккаунта" для спота, марджина и фьючерсов, и схема расчёта обеспечения из-за этого действительно несколько необычная (фактически она учитывает нереализованную прибыль). Если интересно, можете почитать тут и тут.
Почему простые фичи — самые сложные: история о пет-проекте, Дженге и маржинальной торговле