Библиотеки: BestInterval - страница 22

 
Я исправил у себя функцию int Set( const DEAL &dDeals[] ), заполнив Lots нулём. Если не там исправил или что ещё пропустил, отпишитесь тогда. Спасибо.
 
traveller00:
Я исправил у себя функцию  int Set( const DEAL &dDeals[] ), заполнив Lots нулём. Если не там исправил или что ещё пропустил, отпишитесь тогда. Спасибо.

Пока сделал только так

        const double Profit = dDeals[i].Profit ? dDeals[i].Profit + SlipPerLot * dDeals[i].Lots : 0;

Остальное править не требуется по лотам. Но есть ошибки, связанные с другим (старые). Надо править.

 
fxsaber:

Пока сделал только так

Остальное править не требуется по лотам. Но есть ошибки, связанные с другим (старые). Надо править.

Обновил. В режиме активированного BestInterval рекомендую использовать эту опцию.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Библиотеки: Virtual

fxsaber, 2019.12.11 12:15

Сложно сказать, когда разработчики исправят ситуацию с нормализацией исходных цен символов и будут ли это делать вообще. Поэтому введен такой режим.
// https://www.mql5.com/ru/forum/321656/page34#comment_14192799
#define TICKS_FORCE_NORMALIZE // Принудительная нормализация цен входящего тика
 

Достаточно неожиданное поведение.

Похоже, что если прогнать 1 раз с Action=false, то он сохранит результат прохода в файл и потом сможет его применить. Но неожиданность в том, что и все показатели вроде Total, RF, DD и тд он тоже сохранит. Другими словами, если потом прогнать с Action=true на другом интервале того же символа, другом символе и тд, он не только применит лучшее время для торговли, но и потом наврёт в логе, выдав старые значения.

 
traveller00:

если потом прогнать с Action=true на другом интервале того же символа, другом символе и тд, он не только применит лучшее время для торговли, но и потом наврёт в логе, выдав старые значения.

Он не показывает значения true-прогона, а показывает данные false-прохода, который был применен. Вы можете менять символ, интервал и т.д., от этого значения, что он показывает, не изменятся. Они имеют отношение только к тому моменту, когда была запись. Сделано это специально.

 
На всякий случай отмечу, что с точки зрения архитектуры не совсем корректно работает со StopLoss. Теоретически сработавший при action=false StopLoss может попасть в диапазон, который BestInterval решит выкинуть. В итоге при action=true он сместится, и цифры результата порой могут очень сильно отличаться от прогнозируемых при action=false.
 
traveller00:
На всякий случай отмечу, что с точки зрения архитектуры не совсем корректно работает со StopLoss. Теоретически сработавший при action=false StopLoss может попасть в диапазон, который BestInterval решит выкинуть. В итоге при action=true он сместится, и цифры результата порой могут очень сильно отличаться от прогнозируемых при action=false.

Похоже, что-то Вы себе неправильно представляете. Даже теоретически не должно быть проблем.

 
Да, похоже, дело в том, что Sync, который входит в Virtual и который использует BestInterval, игнорирует StopLoss и TakeProfit. Вопрос не архитектурный, это я не до конца разобрался.
 
traveller00:
Да, похоже, дело в том, что Sync, который входит в Virtual и который использует BestInterval, игнорирует StopLoss и TakeProfit. Вопрос не архитектурный, это я не до конца разобрался.

ТС пишу через лимитники и тейки, поэтому хорошо бы примитивный пример воспроизведения проблемы показать.

 
При active=true в BestInterval.mqh есть void OnTickvoid ), внутри неё SYNC::Positions<BEST_TIME>();, которая приведёт в Sync.mqh в static void Positions( const int Handle = 0const bool Reverse = false ). Внутри пересчитываются лоты и если попадают в нужный интервал переносятся из виртуальной среды в реал через SYNC::NewOrderSend(_Symbol, Type, ::MathAbs(AddLots), Price, 10000);.  Тут немного странновато, что цена берётся не из позиций, а считывается на месте, но это ладно. Как видно, передаются нулевые StopLoss и TakeProfit. Возможно, Вы пользуетесь опцией BESTINTERVAL_LIMITSYNC_NETTING, там TakeProfit учитывается.