[Советник] Forex Setka Trader Mod и [EA]-Setka

[Старик]

9 часов назад, Старик сказал:

12 часов назад, egor8777 сказал:

 

Спойлер

Что касается закрытия ордеров без TP и нескольких ордеров рядом, это у меня это частая ситуация на сетах с мелким TP. Бот не успевает выставить TP для ордера (это же делается не сразу), цена идёт в нужную сторону, достигает величины TP и бот закрывает ордер, сигнал ещё актуален и выставляется следующий ордер. Тут мне кажется ошибки нет, главное чтобы всё было последовательно.

  7 часов назад, ademen сказал:

  7 часов назад, ademen сказал:

Аналогичная ситуация, которая была с usdjpy - несколько ордеров открылись и тут же захлопнулись. Возможно в этот раз причина другая, так как иная торговая сессия.

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

 

Версия бота: (EA) - Setka v1.43-ADX-IMP-opt-R295-SR10

Билд терминала: 1280

 

Прилагаю скрины сделок за сессию с 19 на 20 августа.

 

Робо

  Показать контент

 

Тикмилл

  Показать контент

 

 

 

У вас 19 августа вечером тоже отклонение от нормы - ордера в т.ч. единственного первого колена должны закрываться по ТР с выставлением ТР.

Не выставление ТР уже не норма (хотя ТР в районе 5 пипсов и менее есть провокация сбоя в торгах на первом ордере сетки).

 

Судя по обширной географии отклонений, поток котировок USDJPY в районе 21:04 был мерзопакостный у всех - скорее всего, т.н. "дребезжание" цены.

На ваших качественных $$ счетах бот разрулил проблему "истерики котировок" и все ордера закрыл в пусть меньшую, но прибыль.

Но на любых центовиках провокации типа ТР=5пп могут доводить до сбоев в торгах - бот может не успеть "разрулить" микроприбыль на ерзающей цене.

 

Это ж только в кино герои танцуют вальс на крышах качающихся вагонов мчащегося поезда...  Ну еще в тестере стратегий подобное возможно...

Но когда вы загоняете бота на реальный счет и говорите "танцуй вальс", когда землетрясение - то моментами боту ох как сложно вальс танцевать...

@egor8777 большое спасибо за важную информацию и превосходные скрины! 

[Старик]

19 часов назад, ademen сказал:

Брокер : F4y, NDD No Swap

Сет: error set.set

Сборка: 1280

Спред : Поставил индикатор, позже прикреплю отчет. Спред на счету один из наинизших, но комиссия очень большая.

Было бы идеально, если бы вы выложили скрины наподобие @egor8777 , можно из истории счета - или стэйтмент торгов за вчерашний день.

Коллега @elavr взял на себя труд вручную свести информацию из ваших логов в таблицу информации об этом проблемном эпизоде в торгах.

Спойлер

Это большой (и бесплатный) труд расшифровывать логи торгов и осмысленно обобщать информацию...

И нам было бы намного легче разбираться с этим эпизодом, если бы на руках была инфа из истории счета с включенным показом комиссии и комментариев ордеров.

[ademen]

9 минут назад, Старик сказал:

Было бы идеально, если бы вы выложили скрины наподобие @egor8777 , можно из истории счета - или стэйтмент торгов за вчерашний день.

Коллега @elavr взял на себя труд вручную свести информацию из ваших логов в таблицу информации об этом проблемном эпизоде в торгах.

@Старик прикрепил детализирований отчет и так же скрин спреда, как вы просили.

DetailedStatement.htm

[keccak]

Коллеги, спасибо за инфу.

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

Выгрузил инфу только с Робо.

@egor8777 думаю абсолютно прав.

Постараюсь в выходные добраться до сервака.

 

P.S. но по ощущениям - проблем в этот раз не было) но вполне могли и быть - рискованным делом занимаемся))

 

Поправка: Настолько заколебался, что забыл файлик  прикрепить))

robofx.xlsx

Изменено 20 августа, 2020 пользователем keccak

[Aldar]

Добрый день,возник вопрос. Если в параметре  "S_Mult=1. 4" поставить коэффициент меньше единицы,будет ли последующий лот уменьшаться?Спасибо.

[Старик]

@Aldar не помню.  Проверьте в тестере.

 

Корректировать в настройках значение мульта на 3-х коррекциях можно в плюс и минус - как можно корректировать размер шага и ТР, увеличивая или уменьшая.

Точно можно уменьшать множитель лота от колена к колену, пока мульт очередного колена остается положительный (мульт>0) - это встречалось в сетах.

Ну, отрицательными в любой сетке шаг и мульт быть не могут - это очевидно.  Никогда ни на каком колене.

ТР может быть отрицательным, если явно разрешите в настройках и контроле TakeProffitControlNoLossFixPips <0 - иначе бот не пропустит.

 

А вот именно стартовый/первый применяемый Mult меньше единицы, чтобы на каком-то участке строилась сетка из уменьшающихся ордеров - это не помню.

И в такой сетке невозможно применить ограничивающий параметр MaxLotCoef - так как 0<мульт<1 это уже малость потусторонняя, форс-мажорная логика...

 

То, что вы хотите, пока мульт очередного колена остается положительный (мульт каждого колена>0) - логике сеток прямо не противоречит.

Но настройку Mult<1 может не пропустить входной контроль настроек бота.

И, честно, нет времени искать в сотне проверок допустимости настроек бота допустим ли Mult<1.

 

Намного проще вам попробовать прогнать полной версией любого мода бота 2-х недельный тест на любой паре - и еще на старте теста (до теста) бот вам или разрешит, или запретит торги с Mult<1.

Я же этого делать не буду: моя задача прояснить что допустимо в сетках и что вы сломаете в торгах такими настройками - а вы уже разбирайтесь дальше.

[Старик]

В 20.08.2020 в 22:19, keccak сказал:

@egor8777 думаю абсолютно прав.

Постараюсь в выходные добраться до сервака.

 

P.S. но по ощущениям - проблем в этот раз не было) но вполне могли и быть - рискованным делом занимаемся))

Если вы торгуете несколькими копиями бота на одной паре, то в каждой копии бота должен быть отличающийся магик!!  Безоговорочно!

[Rigal]

В 13.08.2020 в 23:12, Старик сказал:

Но вы правы: при TakeProffitType=0, если все ордера на месте и того же лота - первый раз вычисленный ТР с ходом времени меняться не должен.

Потому что при TakeProffitType=0 это простейшая арифметика: умножаются цены открытия ордеров на их лоты - и сумма делится на сумму лотов ордеров сетки.

В любой существующей сетке, которую не корректировали руками, в этой простейшей формуле нет переменных - и один раз высчитанный ТР д.б. неизменен.

И если вдруг, пусть в ролловер и на демке (как в вашем случае), вдруг начало меняться расстояние до ТР, то терем врет боту либо про лоты, либо про цены открытия ордеров.

Где-то до 1260 билда включительно чудес в торгах практически не было, а вот примернно с 1260+ на покореженном короной/трампом рынке отдельные чудеса наблюдаются.

простите меня, гуру сеток, но нет.

 

Давайте разберемся, как мы считаем тейк профит 

Мы для этого вычисляем уровень безубытка и прибавляем, или вычитаем, в зависимости от направления.

А как мы считаем безубыток?

Правильно, из цены закрытия вычитаем дистанцию, полученную делением текущего профита на стоимость пункта в валюте депозита, ака TICKVALUE

Ну и мелочи в виде TICKSIZE

Ну, то есть я опущу сумеречную зону расчета TICKVALUE в тестере целиком и потенциально разные TICKSIZE от тика к тику - я полагаю, разработчики знают свое дело и не кэшируют значения, поэтому для вычисления на тике будет использоваться значение на тике (и потоковая модель, вроде, обещает консистентность расчетов на тике, то есть новый тик, пришедший в терминал с удвоенным значением TICKSIZE не должен повлиять на расчеты, выполняемые на предыдущем тике)

Но, в мт5, например, ввели разное значение TICKVALUE для loss & profit.

Сделано это потому, что значения, которые использует метатрейдер внутри, особенно если торгуется пара, не содержащая валюту депозита в качестве Base (второй валюты) различается на спред курса конвертации в валюту депозита.

И когда мы в мт4 используем одно и то же значение для вычисления безубытка по совокупности ордеров (с учетом свопов и комиссий) - мы не попадаем в безубыток точно.

Только приблизительно

Еще хуже работает в тестере - вообще не совпадает значение, которое использует для вычисления прибыли и убытка тестер с тем, которое советник получает по запросу.

Поэтому тестирование советника на кроссах, или на недолларовом депозите, если разработчик не предпринял специальных мер по пересчету TICKVALUE напоминает гадание на кофейной гуще.

Я видел довольно пожилые версии кода сетки, там использовалось TICKVALUE из терминала, в том числе в тесте.

Пожалуйста, скажите мне, что эту механику переписали?

[keccak]

2 часа назад, Старик сказал:

Если вы торгуете несколькими копиями пота на одной паре, то в каждой копии бота должен быть отличающийся магик!!  Безоговорочно!

Всё верно разные мэджики на каждой копии бота.

[Виталий2701]

Салют господа! Я может и в правду "олбанским" языком владею и вопросами, но откопать 295 версию бота упорно не могу))) Старик, прости меня! Сам от себя уже не могу ржу!))) Ну в упор не вижу!) Есть конечно подозрение, что , как написано на первой странице, что рабочая 285-я версия и 295-ю мне пока не найти!))))) НО я же вижу, как люди оптят на 295! вот тут я и зависаю!))) У Вас тут всё так интересно и много, что уже рябит в глазах! ссылки...ссылки...ссылки....надо буфер почистить!)

[Zmanovskiy]

4 минуты назад, Виталий2701 сказал:

Салют господа! Я может и в правду "олбанским" языком владею и вопросами, но откопать 295 версию бота упорно не могу))) Старик, прости меня! Сам от себя уже не могу ржу!))) Ну в упор не вижу!) Есть конечно подозрение, что , как написано на первой странице, что рабочая 285-я версия и 295-ю мне пока не найти!))))) НО я же вижу, как люди оптят на 295! вот тут я и зависаю!))) У Вас тут всё так интересно и много, что уже рябит в глазах! ссылки...ссылки...ссылки....надо буфер почистить!)

Держите, просто помню сам искал, через поиск файлов на форуме не нашел. Сейчас даже и не вспомню как нарыл (может по пути попался при изучении форума, пусть будет тут) 

(EA) - Setka v1.43-R295-SR10.ex4

[Zmanovskiy]

14 минут назад, Виталий2701 сказал:

Салют господа! Я может и в правду "олбанским" языком владею и вопросами, но откопать 295 версию бота упорно не могу))) Старик, прости меня! Сам от себя уже не могу ржу!))) Ну в упор не вижу!) Есть конечно подозрение, что , как написано на первой странице, что рабочая 285-я версия и 295-ю мне пока не найти!))))) НО я же вижу, как люди оптят на 295! вот тут я и зависаю!))) У Вас тут всё так интересно и много, что уже рябит в глазах! ссылки...ссылки...ссылки....надо буфер почистить!)

Хотя в данный момент попробовал забить по названию в файлах темы, находит спокойно, аж две штуки не считая выложенный мною файл.

Изменено 21 августа, 2020 пользователем Zmanovskiy

[Виталий2701]

Только что, Zmanovskiy сказал:

Держите, просто помню сам искал, через поиск файлов на форуме не нашел.

Вот я тоже изнасиловал поисковик и толку ноль!)) Кланяюсь! Спасибо! Можно продолжить чтиво со спокойной душой! Скачано!!))

[Виталий2701]

Только что, Zmanovskiy сказал:

Хотя в данный момент попробовал забить по названию в файлах темы, находит спокойно, аж две штуки не считай выложенный мною.

Ну это может значить одно, что кривизна моих рук мне еще не известна до конца!))) Еще раз спасибо.

[capteen]

42 минуты назад, Виталий2701 сказал:

Салют господа! Я может и в правду "олбанским" языком владею и вопросами, но откопать 295 версию бота упорно не могу))) Старик, прости меня! Сам от себя уже не могу ржу!))) Ну в упор не вижу!) Есть конечно подозрение, что , как написано на первой странице, что рабочая 285-я версия и 295-ю мне пока не найти!))))) НО я же вижу, как люди оптят на 295! вот тут я и зависаю!))) У Вас тут всё так интересно и много, что уже рябит в глазах! ссылки...ссылки...ссылки....надо буфер почистить!)

Чистка "буфера", опасаюсь не поможет. Все проще  и прозаичнее. 295-я не официальная версия, потому в топике не публиковалась, и есть только у меня на г-диске (адрес в подписи). Никакой "магии".

 

Это была первая, робкая попытка "разгона" опта. Более, она ничем от 285-й не отличается.

 

Изменено 21 августа, 2020 пользователем capteen

[capteen]

2 часа назад, Rigal сказал:

Я видел довольно пожилые версии кода сетки, там использовалось TICKVALUE из терминала, в том числе в тесте.

Пожалуйста, скажите мне, что эту механику переписали?

Вынужден Вас разочаровать. Других средств к получению TickValue и TickSize, кроме данных из терма, не используется.

 

А как бы Вы предложили эту "механику" переписать? Вместо ДЦ рассчитывать цену тика и его объем в валюте депозита? Это как?

 

Без подколок! Если иметь внятный алгоритм, это можно внедрить! Однако надо учитывать, что это задача по-тиковая! Сложный расчет"убъет", и без того, не выдающуюся производительность бота. Поэтому следует, сначала, оценить степень влияния изменения этих данных на результаты расчетов.

 

И еще момент! Цена и объем тика указаны в спецификации инструмента. Т.е. являются константой.

Изменено 21 августа, 2020 пользователем capteen

[Старик]

2 часа назад, Rigal сказал:

В 13.08.2020 в 18:12, Старик сказал:

Спойлер

Но вы правы: при TakeProffitType=0, если все ордера на месте и того же лота - первый раз вычисленный ТР с ходом времени меняться не должен.

Потому что при TakeProffitType=0 это простейшая арифметика: умножаются цены открытия ордеров на их лоты - и сумма делится на сумму лотов ордеров сетки.

В любой существующей сетке, которую не корректировали руками, в этой простейшей формуле нет переменных - и один раз высчитанный ТР д.б. неизменен.

И если вдруг, пусть в ролловер и на демке (как в вашем случае), вдруг начало меняться расстояние до ТР, то терем врет боту либо про лоты, либо про цены открытия ордеров.

Где-то до 1260 билда включительно чудес в торгах практически не было, а вот примернно с 1260+ на покореженном короной/трампом рынке отдельные чудеса наблюдаются.

 

простите меня, гуру сеток, но нет.

Спойлер

Давайте разберемся, как мы считаем тейк профит 

Мы для этого вычисляем уровень безубытка и прибавляем, или вычитаем, в зависимости от направления.

А как мы считаем безубыток?

Правильно, из цены закрытия вычитаем дистанцию, полученную делением текущего профита на стоимость пункта в валюте депозита, ака TICKVALUE

Ну и мелочи в виде TICKSIZE

Ну, то есть я опущу сумеречную зону расчета TICKVALUE в тестере целиком и потенциально разные TICKSIZE от тика к тику - я полагаю, разработчики знают свое дело и не кэшируют значения, поэтому для вычисления на тике будет использоваться значение на тике (и потоковая модель, вроде, обещает консистентность расчетов на тике, то есть новый тик, пришедший в терминал с удвоенным значением TICKSIZE не должен повлиять на расчеты, выполняемые на предыдущем тике)

Но, в мт5, например, ввели разное значение TICKVALUE для loss & profit.

Сделано это потому, что значения, которые использует метатрейдер внутри, особенно если торгуется пара, не содержащая валюту депозита в качестве Base (второй валюты) различается на спред курса конвертации в валюту депозита.

И когда мы в мт4 используем одно и то же значение для вычисления безубытка по совокупности ордеров (с учетом свопов и комиссий) - мы не попадаем в безубыток точно.

Только приблизительно

Еще хуже работает в тестере - вообще не совпадает значение, которое использует для вычисления прибыли и убытка тестер с тем, которое советник получает по запросу.

Поэтому тестирование советника на кроссах, или на недолларовом депозите, если разработчик не предпринял специальных мер по пересчету TICKVALUE напоминает гадание на кофейной гуще.

 

да, всё верно: в приведенной цитате я написал неверно - без цены пипса БУ и ТР не высчитаешь.   

А цена пипса в половине пар плавает и, вместе с мт4, может внезапно и сильно огорчать...

 

Я сейчас свожу воедино все проблемки в торгах последнего времени - надо обобщить и хорошо подумать...

По памяти львиная доля сбоев в торгах в мт4 с билда более 1260.

 

Спасибо, что обратил внимание и на эту некорректность в посте, и на узкое место именно в этом вопросе! 

Был бы признателен и за пример кода, объясняющий подход к решению проблемы - можно в личку.

 

-----

 

55 минут назад, Виталий2701 сказал:

58 минут назад, Zmanovskiy сказал:

Хотя в данный момент попробовал забить по названию в файлах темы, находит спокойно, аж две штуки не считай выложенный мною.

Ну это может значить одно, что кривизна моих рук мне еще не известна до конца!))) Еще раз спасибо.

Всё тот же роковой первый пост:

Индикаторные моды ADX-IMP и RSI-CCI-AS бота (EA) - Setka от @capteen 2019 года, мт4 и мт5

 

  null (Скрыть контент)

http://tlap.com/forum/laboratoriya-profitfx/24/open-source-sovetnik-forex-setka-trader-mod-i-ea-setka/2738/?do=findComment&comment=442192  мт4+мт5

Краткое описание параметров, управляющих работой с индикаторами в моде ADX-IMP

 

Рабочие материалы, включая не публиковавшиеся версии https://drive.google.com/open?id=1uudmEW-wYDVvYIDbNzL-wYzv8iITqXil

Последняя ссылка содержит в т.ч. архив со всеми безиндикаторными и индикаторными модами для мт4 и мт5 релиза 295.

295 релиз был промежуточным/рабочим и в топике не публиковался.

[Rigal]

8 часов назад, capteen сказал:

Вынужден Вас разочаровать. Других средств к получению TickValue и TickSize, кроме данных из терма, не используется.

 

А как бы Вы предложили эту "механику" переписать? Вместо ДЦ рассчитывать цену тика и его объем в валюте депозита? Это как?

 

Без подколок! Если иметь внятный алгоритм, это можно внедрить! Однако надо учитывать, что это задача по-тиковая! Сложный расчет"убъет", и без того, не выдающуюся производительность бота. Поэтому следует, сначала, оценить степень влияния изменения этих данных на результаты расчетов.

 

И еще момент! Цена и объем тика указаны в спецификации инструмента. Т.е. являются константой.

@capteen, да, я долгое время считал, что TickSize - это константа

Забирал ее на старте советника и использовал.

В определенный момент обнаружил, что расчеты получаются неустойчивые и после некоторого количества раскопок наткнулся на вот этот пост:

https://www.mql5.com/en/forum/133792/page3#comment_3405179

Фрагмент:

     * https://www.mql5.com/en/forum/127584 CB: MODE_TICKSIZE will usually return the
     * same value as MODE_POINT (or Point for the current symbol), however, an
     * example of where to use MODE_TICKSIZE would be as part of a ratio with
     * MODE_TICKVALUE when performing money management calculations which need
     * to take account of the pair and the account currency. The reason I use
     * this ratio is that although TV and TS may constantly be returned as
     * something like 7.00 and 0.0001 respectively, I've seen this
     * (intermittently) change to 14.00 and 0.0002 respectively (just example

Я перевел все на опрос терминала в реальном времени, на тике, на котором выполняется расчет.

После этого на реале все стало выглядеть более-менее предсказуемо, а в тестере результат все еще был неустойчив для кроссов.

Причина проста: чтобы посчитать прибыль/убыток по сделке в валюте депозита в случае, когда валюта депозита не является базовой валютой пары, нужно иметь котировку между базовой валютой пары и валютой депозита.

Которой у тестера, конечно, нет для кроссов, но он использует какую-то величину. И при этом это не та же величина, которую он возвращает советнику по запросу TickValue

Мы это обсудили вот тут: https://www.mql5.com/en/forum/336141

В итоге я стал в тестере использовать аппроксимацию: зная дистанцию, которую прошла каждая сделка в прибыль, или в убыток и начисленный на эту дистанцию профит, можно вычислить TickValue, которое тестер использовал в вычислениях: TesterTickValue = DirectionSign * OrderProfit / (ClosePrice - OrderOpenPrice) / OrderLots * tickSize

Здесь  DirectionSign = 1 для BUY  и -1 для SELL

Раздельно для всех ордеров - потому, что тестирование показало, что эта величина будет различаться от ордера к ордеру, как это ни парадоксально.

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

Полученные уровни безубытка можно слить, как Volume Weighted Average Price: (Lots1 * Breakeven1 + Lots2 * Breakeven2 + ...) / (Lots1 + Lots2 +. ...)

Следует помнить, что VWAP требует смены знака лота при слиянии сделок разного направления (и ожидаемо делает невозможным вычисление общего уровня безубытка полностью захеджированной позиции - этот уровень бесконечно далеко)

 

Зачем все это?

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

Изменено 22 августа, 2020 пользователем Rigal

[Rigal]

8 часов назад, Старик сказал:

Был бы признателен и за пример кода, объясняющий подход к решению проблемы - можно в личку.

Я описал подход. У меня довольно глубоко в библиотеках эти вычисления и с кандачка не выкусишь - очень много контекста потянется.

Я, тем не менее, выпишу отдельным кусочком, который будет вычислять безубыток позиции и выложу сюда, чтобы не путаться.

[Rigal]

А, и чтобы добить этот вопрос:

Поскольку котировка из базовой валюты в валюту депозита постоянно меняется для пар, в которых базовая валюта не совпадает с валютой депозита, наша TickValue тоже постоянно меняется. Как меняется и величина, возвращаемая метатрейдером по MarketInfo или SymbolInfoDouble.

Это никак не влияет на расположение точки безубытка по торговому профиту - там все понятно, безубыток в цене открытия.

Но как только мы добавляем в расчет комиссию и своп (и пересчитываем их в пункты) - вот тут наша непрерывно меняющаяся котировка будет непрерывано двигать нашу точку безубытка.

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

Об этом я и хотел сказать исходно, когда прокомментировал, что единожды поставленный, тейк не должен двигаться, если не изменились свопы.

Будет он двигаться.

[Rigal]

Советник - демо

Открывается случайным образом раз в час с тейком и стопом.

На каждом тике:

- считает безубыток в покупку двумя способами - штатный TickValue и рассчитанный по профиту сделок и усредненный,  рисует две голубые линии, логгирует расхождение двух значений, если включена опция Noisy

- то же самое для продаж, коралловым цветом

- то же самое для полной совокупности, жирная желтая линия

- ловит моменты, когда сумма прибыли выходит в ноль по продажам, покупкам и совокупности, сравнивает с вычисленными безубытками и сообщает результат в логе

Если запустить советника в тестере с долларовым депозитом на евродолларе, все уровни будут практически неподвижны в отсутствие новых позиций, свопов и прочих изменений состояния. Мелкий подрагивания на один пункт в силу ошибок округления, не более того.

Это ожидаемо - TickValue остается константой.

А вот если запустить его на, скажем, USDJPY (где, казалось бы, у метатрейдера по-прежнему всегда есть котировка, чтобы превратить йену в доллар, ибо это та же котировка) и посмотреть, что происходит, можно заметить, что уровень, вычисляемый по тестерному TickValue непрерывно плавает - и плавает тем сильнее, чем дальше от него уходит цена.

При этом характерно, что при приближении к этому уровню, он сдвигается в ту же позицию, где находится уровень, который я рассчитываю самостоятельно.

И при прохождении через безубыток эти два уровня сливаются в один,  советник репортит оба, как точные.

 

Если задуматься о том, какие последствия это будет вызывать в тестере, легко понять, что при вычислении безубытка сетки традиционным методом, чем выше колено, тем дальше от реального безубытка будет вычисленное значение.

И, если советник поправляет тейки и стопы на каждом тике, он будет их передвигать по мере приближения к безубытку.

А если он написан разработчиком,  пытавшимся сделать код оптимальным (и обоснованно ожидающим, что, без изменения позиции тейки переставлять не нужно) - то тейк так и останется в неправильном месте и, когда сделки закроются, они принесут прибыль заметно меньше расчетной.

Или наоборот, пару пунктиков не дотянет до выставленного тейка потому, что он был выставлен чуть дальше, чем было нужно - тут как повезет с величиной.

 

Поэкспериментируйте с этим перцем на разных парах в визуале.

При наведении на уровень, подсвечивается его имя.

Если имя заканчивается на заглавную Т - это уровень, построенный по значению TickValue из тестера.

Если буквы Т нет - уровень вычислен по отношению профита к дистанции.

 

И сразу оговорюсь: советника я накидал исключительно для демонстрации феномена.

Он крайне неоптимален, пересчитывает. все сделки по много раз на тике и ни в коей мере не отражает мое отношение к разработке.

Просто структурированная демонстрация проблемы.

BreakEvenCompare.mq4

[Старик]

В 02.02.2020 в 11:28, kvv75 сказал:

в Robo я вообще на разобрался и не увижу где момент закрытия

Кстати да, в вашем терминале от Робо в Истории счета (между ТР и ценой закрытия) нет столбца "Время" с временем закрытия - и я не понял как его можно on|off.

При том, что у меня в терминалах Робо и везде это крайне важный столбец есть - но я делаю новые терминалы полным копированием старых (у меня они все portable).

Возможно, что вам стоит скопировать метаквотовский терем (скачать не из ДЦ) и уже его подключить к Робо.

 

Но, коллега @kvv75 , я вам пишу по другой причине - у вас были удивительные сбои в 2-х ДЦ с обновления терема в январе 2020 (до этого ничего подобного не было).

Мы некую дополнительную защиту на ваш случай добавили и еще подумаем/проверим достаточно ли её или еще надо думать и писать код - и пока не опубликовали.

Но очень хотелось бы знать были ли у вас рецидивы этих проблем - и, если рецидивов не было, то предпринимали ли вы что-то, что улучшило ход ваших мультиторгов.

[Старик]

@Rigal огромное спасибо и за осветление очень непростого и "подставочного" вопроса - и за потраченное время на написание этих наполненных смыслом постов!

Точно будет и что потестить, и над чем много раз подумать...

Проблема, несомненно, в этом есть - и в мт4 она намного сложней, чем в мт5 с намного большим объемом более широкой и точной информации.

Блин, между мт4 и мт5 намного больше отличий, чем хотелось бы...

 

Мы пока реализовали (пока не опубликованный по другим причинам) несколько более прагматичный подход.

Насколько помню, у части пар цена пипса фиксированная, а у остальных (за время жизни сетки) плавает в пределах доли% или 1%-2% . И 1% уже немало.

Т.е. в TickValue max меняется 2-3 знак после запятой и очень небыстро, сетки на откатах намного чаще закрываются быстрей значимых изменений TickValue. 

А новая сетка новые цены пипса - ну и ладно...

И к тому же сетки закрываются на откате, в ходе которого цена пипса возвращается к тем средним значениям, которые были в момент разворачивания сетки...

Комиссия у каждого ордера фиксированная с момента открытия ордера (на закрытии могут доначислить, но это фиг вычислишь), а своп в $ после начисления фикс сутки+.

В итоге, при расстоянии до ТР от 5 до 100+ пипсов 4-х знак, в абсолютном большинстве случаев среднее изменение цены пипса меняет уровень ТР на долю пипса.

 

Исходно у нас ТР пересчитывался и модифицировался после открытия/выставления каждого ордера и по таймеру (дефолтно каждые 90 секунд, можно чаще).

Уже достаточно большая история торгов даже в долго висящих сетках очень редко показывала модификацию ТР в течение суток, кроме как после начисления свопа в ролловер.

В итоге не в точности, но мы частично реализовали идею, что если пересчитанный уровень ТР отличается менее чем на 1 пипс 4-х знак, то нехер модифицировать.

Это в сотни раз уменьшило частоту модификаций ТР сеток - что, в т.ч., несколько повысило скорость тестирования бота без существенного изменения результатов тестов.

 

К сожалению, как показывает изложенная вами информация, это всё же скорее торгово-технологический компромисс.   

И всё же скорее придется выписать дополнительные анализ и контроль - для избежания проблем наподобие рассматривавшегося инцидента у коллеги @kitaro_777.

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

[Rigal]

Вот, кстати, хороший пример на USDJPY

БОльшая часть позиции - продажи. Открыта одна позиция в покупку.

Безубыток, пересчитанный из соотношения прибыли этого ордера к дистанции до цены закрытия,  торчит там, где мы его ожидаем: немного над точкой входа. Это своп и комиссия.

Безубыток, пересчитанный из TickValue,  которое вернул терминал, находится под  сделкой, на заметном расстоянии.

Если я где-то ошибся в коде, или чего-то принципиально недопонимаю, я буду рад услышать комментарии.

Но изменения, которые требуются в расчетах - это вычисление tickValue из OrderProfit и дистанции между ценой закрытия и ценой открытия.

Разные для покупок и продаж

         if(MathAbs(OrderProfit()) < 0.01 || MathAbs(cp(_tick, OrderType()) - OrderOpenPrice()) < DBL_EPSILON) {
            if(tickValue[OrderType()] < DBL_EPSILON)
               tickValue[OrderType()] = SymbolInfoDouble(Symbol(), SYMBOL_TRADE_TICK_VALUE);
         } else {
            tickValue[OrderType()] = sgn(OrderType()) * OrderProfit() / (cp(_tick, OrderType()) - OrderOpenPrice()) / OrderLots() * tickSize;
         }

И потом использовать этот TickValue для вычисления безубытка. Опять же, раздельный для покупок и продаж.

И при вычислении общего безубытка (если это делается в сетке, хотя мне кажется, что нет) - использовать TickValue для направления в сухом остатке.

В целом, вычисление несложное. 

Вопрос, конечно, как и куда оно там вписывается.

[Rigal]

10 минут назад, Старик сказал:

@Rigal огромное спасибо и за осветление очень непростого и "подставочного" вопроса - и за потраченное время на написание этих наполненных смыслом постов!

Точно будет и что потестить, и над чем много раз подумать...

Проблема, несомненно, в этом есть - и в мт4 она намного сложней, чем в мт5 с намного большим объемом более широкой и точной информации.

Блин, между мт4 и мт5 намного больше отличий, чем хотелось бы...

Спойлер

Мы пока реализовали (пока не опубликованный по другим причинам) несколько более прагматичный подход.

Насколько помню, у части пар цена пипса фиксированная, а у остальных (за время жизни сетки) плавает в пределах доли% или 1%-2% .

то есть максимум меняется 2-3 знак после запятой и очень небыстро, сетки на откатах намного чаще закрываются быстрей существенных изменений цены пипса. 

А новая сетка новые цены пипса - ну и ладно...

И к тому же сетки закрываются на откате, в ходе которого цена пипса возвращается к тем средним значениям, которые были в момент разворачивания сетки...

Комиссия у каждого ордера фиксированная с момента открытия ордера (на закрытии могут доначислить, но это фиг вычислишь), а своп в $ после начисления фикс сутки+.

В итоге, при расстоянии до ТР от 5 до 100 пипсов 4-х знак максимум, в абсолютном большинстве случаев среднее изменение цены пипса меняет уровень ТР на долю пипса.

 

Исходно у нас ТР пересчитывался и модифицировался после открытия/выставления каждого ордера и по таймеру (дефолтно каждые 90 секунд, можно чаще).

Уже достаточно большая история торгов даже в долго висящих сетках очень редко показывала модификацию ТР в течение суток, кроме как после начисления свопа в ролловер.

В итоге не в точности, но мы частично реализовали идею, что если пересчитанный уровень ТР отличается менее чем на 1 пипс 4-х знак, то нехер модифицировать.

Это в сотни раз уменьшило частоту модификаций ТР сеток - что, в т.ч., несколько повысило скорость тестирования бота без существенного изменения результатов тестов.

 

К сожалению, как показывает изложенная вами информация, это всё же скорее торгово-технологический компромисс и всё же скорее придется выписать дополнительные анализ и контроль - для избежания проблем наподобие рассматривавшегося инцидента у коллеги @kitaro_777.

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

 

 

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

В реальных торгах этого и не будет происходить: на реале величина TickValue в точности соответствует арифметике расчета прибыли/убытка.

Все выкладки относятся к тестам - но было бы здорово, если бы мы могли тестировать то же самое, что советник делает на реале