Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
При active=true в BestInterval.mqh есть void OnTick( void ), внутри неё SYNC::Positions<BEST_TIME>();, которая приведёт в Sync.mqh в static void Positions( const int Handle = 0, const bool Reverse = false ). Внутри пересчитываются лоты и если попадают в нужный интервал переносятся из виртуальной среды в реал через SYNC::NewOrderSend(_Symbol, Type, ::MathAbs(AddLots), Price, 100, 0, 0);. Тут немного странновато, что цена берётся не из позиций, а считывается на месте, но это ладно. Как видно, передаются нулевые StopLoss и TakeProfit. Возможно, Вы пользуетесь опцией BESTINTERVAL_LIMITSYNC_NETTING, там TakeProfit учитывается.
Да, использую этот режим. true-режим больше делался для демонстрации. На универсальное решение даже не думал тратить время, т.к. все было бы убито в пустую.
Если немного поколдовать, то можно BestInterval-true применять для одиночных проходов советников с закрытым исходным кодом (Маркет и т.д.).
Но все же основная фишка BestInterval - это работа в режиме Оптимизации. true - хорошая, но не обязательная фича.
Незначительное косметическое исправление, int => bool. Или, если я могу предложить вернуть AmountDeleteIntervals вместо этого.
Спасибо, надо будет поправить.
Пожалуйста, рассмотрите AverageHolding как дополнение к библиотеке
Interval.mqh
BestInterval.mqh
Пожалуйста, рассмотрите AverageHolding как дополнение к библиотеке
Среднее время жизни закрытой позиции - для чего оно нужно?
Вычислять его нужно не так. Нужно знать время закрытия.
Среднее время жизни закрытой позиции - для чего оно нужно?
Я имею в виду среднее время жизни позиции (OrderCloseTime - OrderOpentime). Это может быть полезно в качестве пользовательских критериев GA. Например, привести GA к увеличению частоты транзакций в сочетании с минимальным порогом прибыли на сделку.
Вычислять его нужно не так. Нужно знать время закрытия.
Для счета неттинга DEAL IN / OUT достаточно времени открытия для расчета, для правильной реализации необходимо использовать время закрытия, которое в настоящее время не учитывается в библиотеке.
Существует проблема, которая останется. Тестер форсирует закрытие последней позиции. Точность атомных часов может понадобиться не для всех стратегий, она останется проблемой. Также GA можно привести к большей частоте торговли, просто вернув 0, когда BestInterval.GetTotal () <xxx, например, как вы написали в каком-то посте.
Таким образом, это выглядит не стоит, пока неприятности преследуют.
Я имею в виду среднее время жизни позиции (OrderCloseTime - OrderOpentime). Это может быть полезно в качестве пользовательских критериев GA. Например, привести GA к увеличению частоты транзакций в сочетании с минимальным порогом прибыли на сделку.
Приведите критерий оптимизации в виде схематичного исходного кода OnTester-функции.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Библиотеки: BestInterval
fxsaber, 2019.12.05 13:48
Сказать, что я доволен - явно преуменьшить... BestInterval теперь крут. А изменения минимальны. Как всегда, пример.
Вот круглосуточный проход.
Применяем классический BestInterval.
Видим, что на треть увеличился профит, ну и другие показатели стали лучше.
Но хотелось гибкости. И вот она.
Профит не увеличился, а уменьшился! Но посмотрите на другие показатели. Вместо того, чтобы найти интервал с самым большими профитом и вероятностью подгонки, был найден гораздо более узкий интервал, но куда вкуснее, чем классика.
Новшество добавляется так
Теперь очень сильно повысилось качество исследования рыночных закономерностей. Существенные последствия для мультитестерных работ.
Интересно, что если найденный так вкусный интервал забить в ТС и начать ее оптимизировать на максимальный профит в нем, то высока вероятность, что будет найдена фигня.
И еще такое замечание. BestInterval, например, игнорит сделки, открытые с полуночи до часа. Это вовсе на значит, что если в два часа придет сигнал на открытие, то BestInterval даст ее открыть. Библа даст открыть только в том случае, если проигноренная позиция с полуночи будет "закрыта". Поэтому можно видеть часто, что оптимизация ТС с жестко заданным интервалом дает более плохие результаты, чем показывает BestInterval.
Самый наглядный пример - это контртрендовая ТС на тренде. Допусти, ТС дает сигнал SELL, а тренд прет вверх. BestInterval будет игнорить эти сигналы.
Заметил такую особенность, которая основывается на своем опыте.
Если критерий Оптимизации никак не связан с гладкостью кривой профита. И лучший результат все же дает гладкую кривую, то это не подгонка.
Например, критерий - максимальная прибыль. И в результате лучший проход - прямая вверх. Это не подгонка.
А вот если критерий - минимальный R^2. И в результате лучший проход - прямая вверх. То это, скорее всего, подгоночка.
У меня дилемма, BestInterval - независимый критерий Оптимизации или нет? Особенно, с его фишкой задания Slippage.
Т.е. он говорит, что если игнорить все сделки, не попадающие в интервал 18:00-12:00, то на истории будет все красиво.
Зашиваю в ТС этот интервал, делая ТС уже не круглосуточной, и оптимизирую по максимальному профиту.
Лучший проход генетики, мягко говоря, мусор.
ЗЫ Это еще слабый пример. Встречается, когда BestInterval имеет PF > 3, а Оптимизатор выдает PF < 1.