Библиотеки: Virtual - страница 54

 
Forester #:

отличия только из за перестановки строк сделок закрытых на одной миллисекунде

Нарушили хронологию в записи истории ордеров.


 
Forester #:

Лучше конечно как правильнее. Можно сделать переключатель правильно/как в теcтере MQ. Думаю второй вариант тоже будет интересен.

Добавил выключатель

  #define DISABLE_ACCOUNT_LIMIT_ORDERS //- не применять ограничение на число лимитных ордеров аккаунта (сможет добавить любое число) 
....

virtual TICKET_TYPE OrderSend( {
....
  #ifndef  DISABLE_ACCOUNT_LIMIT_ORDERS
    if(Type > 1 ){if(MAX_LIMIT_ORDERS == Current_LIMIT_ORDERS){ return Res; }else{ Current_LIMIT_ORDERS++; }}
  #endif //DISABLE_ACCOUNT_LIMIT_ORDERS
....

Это мне самому точно понадобится.

Файлы:
Virtual.zip  57 kb
 
fxsaber #:

Нарушили хронологию в записи истории ордеров.

Это из за удаленных

//this.IsChange();//закроет лимитки по ТП/СЛ открывшиеся на этом же тике

В OrderClose() и в OrderDelete(). Т.е. закрытые там ордера уходят в архив на следующем тике, потому они и оказались ниже.
Надо сделать отправку в архив без проверок срабатывания всех ордеров на ТП/СЛ.

Добавил Check

  bool IsChange( bool Check = true )
  {
 ......
      if(Check){
         Res |= this.Orders[i].IsChange(this.CurrentTick) && !this.Orders[i].IsClosed();
      }

А в  OrderClose() и в OrderDelete() снова открыл вызов IsChange(), но отключил пересчет ордеров

        this.IsChange( false );//перенести закрытое в архив, без проверок остальных ордеров на ТП/СЛ, если с true, то закроет лимитки по ТП/СЛ открывшиеся на этом же тике, тестер МК на тике открытия не закрывает

Теперь  выглядит так (Gif-ка)


Файлы:
Virtual.zip  57 kb
 

По поводу

  void Check( void )
  {
    _VC
   
    if (this.IsChange())// if вместо while
      if (this.Netting)
        this.CloseBy();

    return;
  }

Может while для неттинга нужна была. Не знаю, неттинг не изучал. Вам как автору виднее. Нужна?
Если она там нужна, то if (this.Netting) можно вынести наверх, и для него делать while. А для хеджинга просто 1 вызов.

 
Forester #:

для хеджинга просто 1 вызов.

IsChange - изменение состояния ордера (открылась/закрылась позиция). Поскольку на одном тике может быть два изменения состояния, то одним if, вроде, не обойтись. Надо вникать для более точного ответа. Этот код не менялся с самого начала написания библиотеки. Тогда на тему производительности не думал точно.

 
fxsaber #:

IsChange - изменение состояния ордера (открылась/закрылась позиция). Поскольку на одном тике может быть два изменения состояния, то одним if, вроде, не обойтись. Надо вникать для более точного ответа. Этот код не менялся с самого начала написания библиотеки. Тогда на тему производительности не думал точно.

Сделал как в тестере MQ. Все 1-м вызовом решается и получается точное совпадение. Кстати и ускорение получим. Это по экспериментам с хеджингом. Про неттинг не знаю может там для CloseBy нужен цикл (хотя в хеджинге частичное закрытие вроде посчиталось правильно, кроме закоментированного закрытия на одном тике).

В принципе можно и 1-м вызовом: после срабатывания лимитки или открытия рыночного, сразу проверять ТП/СЛ и закрывать, если сработали. Так и скорость сохранится, т.к. не будем весь массив проверять 2-й раз на срабатывание ТП/СЛ.

Можно через #define оба варианта сделать правильный / MQ.

Думаю MQ запретили срабатывание на том же тике, как защиту от дурака, который поставил стоп на цену открытия. Хотя одуматься он не успеет, следующий тик приходит обычно очень быстро. Так что без разницы, так и так  потеряет спред+комиссию. А на 1 тик больше или меньше уже не так важно.

Плюс код быстрее, с 1-й проверкой всех ордеров. Может это основной аргумент.

 
Forester #:

Сделал как в тестере MQ. Все 1-м вызовом решается и получается точное совпадение. Кстати и ускорение получим. Это по экспериментам с хеджингом. Про неттинг не знаю может там для CloseBy нужен цикл (хотя в хеджинге частичное закрытие вроде посчиталось правильно, кроме закоментированного закрытия на одном тике).

В неттинге (лет пять не запускал Virtual в этом режиме) необходимо, как минимум, две проверки.

В принципе можно и 1-м вызовом: после срабатывания лимитки или открытия рыночного, сразу проверять ТП/СЛ и закрывать, если сработали. Так и скорость сохранится, т.к. не будем весь массив проверять 2-й раз на срабатывание ТП/СЛ.


Такое рассматривал, не стал заморачиваться. Надо будет посмотреть, раз уж столько изменений.

Думаю MQ запретили срабатывание на том же тике, как защиту от дурака, который поставил стоп на цену открытия. Хотя одуматься он не успеет, следующий тик приходит обычно очень быстро. Так что без разницы, так и так  потеряет спред+комиссию. А на 1 тик больше или меньше уже не так важно.

На терминале такая же ситуация.

Плюс код быстрее, с 1-й проверкой всех ордеров. Может это основной аргумент.

Точно не MQ-аргумент.

 
Forester #:

А так же


В итоге получим точное совпадение с тестером МQ по всем перечисленным ниже тестам.  Анимация результатов обоих тестеров: (тот, что с комментариями - тестер MQ, отличия только из за перестановки строк сделок закрытых на одной миллисекунде)


Думаю можно такой советник считать полной проверкой всех возможных вариантов торговых операций (кроме OrderCloseBy - может вы добавите такую проверку?)



По дате обновления вижу, что вы еще не добавили в свой код пересчет прибыли в валюту депозита, комиссии в % за лот, ежедневные свопы по текущей цене, о которых писал тут https://www.mql5.com/ru/blogs/post/755500.

Вот моя последняя версия библиотеки с ними и с сегодняшними корректировками.

В коде использовал свою ускоренную версию библиотеки Report
//#include <Report.mqh>
#include <MT4Orders_QuickReport.mqh>//
Она работает до 10 раз быстрее и до 5,4 млн строк способна показать.
Только что опубликовал https://www.mql5.com/ru/code/47816
MT4Orders QuickReport
MT4Orders QuickReport
  • www.mql5.com
Быстрая JavaScript версия библиотеки Report от fxsaber для торговых команд в стиле MT4 реализованных через MT4Orders или Virtual. Работает до 10 раз быстрее, размер НТМЛ файлов меньше, может выгрузить и отобразить до 5.4 млн. строк отчета.
 
Forester #:

Стало точно как в тестере МQ

Тогда придется учитывать еще FreezeLevel/StopLevel.

 
fxsaber #:

Тогда придется учитывать еще FreezeLevel/StopLevel.

Да, в одной из версий добавил, из за отличий. Но потом откатил. Решил, что без них мне нужнее. Хотя можно сделать через переключатель. Добавлю сегодня-завтра.
Expiration тоже легко добавить.
И Slippage наверное тоже просто, еще не думал. Да и не знаю как должно быть. Это, если следующий тик < запрошенной цены покупки + Slippage, то разрешаем?