практически 50% всех случаев - это когда длина непрерывающихся трейдов равна "1". То есть имеем ситуации типа: открыли Buy и затем перевернули позицию (то есть закрыли Buy с убытком и открыли Sell) или такая ситуация: открыли Sell и затем перевернули позицию (то есть закрыли Sell с убытком и открыли Buy). Таким образом ситуации с длиной непрерывающихся трейдов равной "1" - это гарантированный убыток.
примерно 25% всех случаев с длиной непрерывающихся трейдов равной "2", на примере Buy: открыли Buy, потом открыли ещё Buy и затем перевернули позицию (то есть закрыли два Buy и открыли Sell - в итоге получили убыток равный нулю).
Думаю, что над этими самыми многочисленными категориями (длина непрерывающихся трейдов равная "1" и "2") нужно подробнее подумать для корректировки стратегии размещения Stop отложенных ордеров.
Проверим идею пирамидинга (для случаев открытия позиции в направлении предыдущей):
1. Вариант увеличения лота в геометрической прогрессии
Геометри́ческая прогре́ссия — последовательность чисел b1, b2, b3, ... (членов прогрессии), в которой каждое последующее число, начиная со второго, получается из предыдущего умножением его на определённое число q (знаменатель прогрессии), где b1!=0, q!=0: b1, b2=b1*q, b3=b2*q.
2. Вариант увеличения лота в арифметической прогрессии
Арифмети́ческая прогре́ссия (алгебраическая) — последовательность чисел (членов прогрессии), в которой каждое число, начиная со второго, получается из предыдущего добавлением к нему постоянного числа d (шага, или разности прогрессии).
С вводом двух типов регрессии возникает необходимость проверять вычисленный размер лота. Для этого будет использоваться функция LotCheck. Пример использования этой функции в скрипте:
Сравнение торговли (символ EURUSD, шаг 35) обычным лотом и с геометрической прогрессией:
Рис. 1. Советник Buy stop Sell stop Grid в виде класса: обычный лот
Рис 2. Советник Buy stop Sell stop Grid в виде класса: лот в геометрической прогрессии
Рис. 3. Советник Buy stop Sell stop Grid в виде класса: лот в арифметической прогрессии
Скажем так: "Увеличение лота в геометрической прогрессии или в арифметической прогрессии при наборе позиций в одном направлении оказывается хуже торговли постоянным лотом".
Для шага 35 расширенные итоги:
Здесь видно, что
Думаю, что над этими самыми многочисленными категориями (длина непрерывающихся трейдов равная "1" и "2") нужно подробнее подумать для корректировки стратегии размещения Stop отложенных ордеров.
Проверим идею пирамидинга (для случаев открытия позиции в направлении предыдущей):
Дополнил первый пост двумя ссылками:
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Советник Buy stop Sell stop Grid в виде класса
Vladimir Karputov, 2017.09.26 19:26
***
Добавлено:
В процессе работы советника в OnTradeTransaction записываются данные в массив. Формат записи такой: если открыта позиция Buy - значит записываем "+1", если была открыта позиция Sell - значит записываем "-1"
Проверим идею пирамидинга (для случаев открытия позиции в направлении предыдущей)
С вводом двух типов регрессии возникает необходимость проверять вычисленный размер лота. Для этого будет использоваться функция LotCheck. Пример использования этой функции в скрипте:
Дабы не засорять журнал терминала весь вывод организован на график:
В класс советника добавлены геометрическая и арифметическая профессии. Реализован расчёт лота (пока) для геометрической прогрессии.
ds
Сравнение торговли (символ EURUSD, шаг 35) обычным лотом и с геометрической прогрессией:
Рис. 1. Советник Buy stop Sell stop Grid в виде класса: обычный лот
Рис 2. Советник Buy stop Sell stop Grid в виде класса: лот в геометрической прогрессии
Рис. 3. Советник Buy stop Sell stop Grid в виде класса: лот в арифметической прогрессии
Скажем так: "Увеличение лота в геометрической прогрессии или в арифметической прогрессии при наборе позиций в одном направлении оказывается хуже торговли постоянным лотом".
Что-то у меня при попытке обновить данные из Хранилища пишет:
2017.10.03 12:59:10.146 Storage failed to read http data (storage.mql5.com:443 read failed [12152])
В общем, никак у меня работа с Хранилищем не налаживается... Что-то я неправильно делаю...Что-то у меня при попытке обновить данные из Хранилища пишет:
2017.10.03 12:59:10.146 Storage failed to read http data (storage.mql5.com:443 read failed [12152])
В общем, никак у меня работа с Хранилищем не налаживается... Что-то я неправильно делаю...Давайте в Skype, а потом здесь выложим решение проблемы с Хранилищем ...
Давайте в Skype, а потом здесь выложим решение проблемы с Хранилищем ...
Без проблем. Написал в личку.
Итак.
У меня Windows7 x64, контроль учетных записей отключен. При каждом входе в метаедитор приходится каждый раз подключаться к Хранилищу.
Владимир, просьба и меня добавить в проект. Спасибо