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

[DENYA]

[Setka1.43][EURUSD M1][2016.01.04-2018.04.19][DD Variable][K54.0][Grid4,Mult1.1,TP15,Corr2][SetA3]

Приветствую! Тест с начала года по сегодня проходит этот сет с 50000?

не пробовал я после 19.04 по сегодня прогонять. 99% что сольет в этот промежуток времени.
основную ЦЕЛЬ, которую преследовал подобрав данный ТИП сета следующий:

1.Теория: если сет БЕЗ стопа, то мы его как бы подгоняем под участок истории. Что говорит что в будущем ОБЯЗАТЕЛЬНО будет другой участок истории, на котором сет бы слил. Это аксиома, вопрос только времени слива, если сет слишком консервативный, с маленькой доходностью в месяц, то просто напросто слив вы отодвигаете во времени, но все равно СЛИВ НЕИЗБЕЖЕН.
2.Какой вывод напрашивается из 1-го пункта? Что при работе с сеткой важно либо вовремя выводить прибыль, ЛИБО подбирать сеты в которых внедрена защита от слива депо.
3.Какую ЗАЩИТУ от слива депо в наборе инструментариев бота мы можем заточить на "защиту от слива"? Правильно, самый лучший вариант - это делать принудительный стоп по определенной просадке (имитация слива с последующем пополнением счета). Беда в том, что такие сеты будут иметь иногда по 6 месяцев стагнации размера прибыли/убытков. Ни роста, ни потерь целых 6 месяцев ...
4.По 1-му варианту работы с Сеткой, а именно с постоянным выводом прибыли я проработал еще одно ответвление:

РЕИНВЕСТ.
С коротким шагом ордеров получается очень много сеток, вплоть до 20 000 ордеров за 2.4 года. Каждое закрытие сетки - это небольшое увеличение БАЛАНСА депо. Грех НЕ использовать увеличение баланса депо для реинвеста.

Используя реинвест (параметр CurrencyForMinLot) сначала мы находим сет для фикс лота. В моем случае это сетА2. В данном сете за 2.4 года увеличение депо в 9 раз. После нахождения сета крутим параметр CurrencyForMinLot, так как округление объема ордеров с увеличением депо отличается. Я подобрал параметр 50 000, на нем и остановился.

Теперь самое главное, а для ЧЕГО это все делается? С реинвестом мы получаем больше прибыль (если БЕЗ вывода прибыли) за тот же самый промежуток времени торгов, что и для фикс лота. Риски по теории вероятности получить слив все же больше нежели с выводом прибыли, но размер прибыли думаю перевешивает.
С таким ТИПОМ сетов торги должны выглядеть следующим образом: Депо около 50% от рассчетного, ждем удвоения рассчетного депо, вывод прибыли. Далее вывод прибыли только через пол годика или год. Причем выводить надо после доооолгого участка по балансу БЕЗ СИСЬ. Чем дольше такой участок, тем вероятноее появление просадки (сись).

Я бы при таком подходе рекомендовал бы использовать не МУЛЬТИсеты на несколько пар, а 1 счет на 1 пару. И отдельный счет копилка для периодического вывода прибыли.

[Старик]

Спойлер

Коллеги!
Первый ,можно сказать черновой, вариант скрипта для сбора статистики по проблемным участкам для сеток. Пока только по сбору, представлением и прочим займусь тогда, когда удостоверимся что собираем то что нужно, а не мусор всякий ;)

Надо тестировать.
Сначала немного о терминах и о том что на графике по результатам работы скрипта.
"Сегмент" -- участок графика с однонаправленным движением без явных минимумов/максимумов внутри. На графике отображается линией из точек;
"Проблемный участок" (ПУ) -- участок графика с однонаправленным движением, состоящий из одного или нескольких сегментов. На графике отображается сплошной жирной линией;
"Откат" -- участок графика с однонаправленным движением, состоящий из одного или нескольких сегментов, следующий сразу за ПУ в противоположном направлении и разницей между Min и Max не менее чем какой-то определенный процент от разницы Min и Max для ПУ. На графике отображается линией штрихов.

ПУ и откат на графике смещены относительно их действительных значений, для улучшения читаемости. Для long сеток вниз, для short -- вверх. Величина смещения задается. Также можно отключить отображение ПУ+Откат одного типа, установив в "None" цвет.

Теперь о том как тестировать.
Кидаете скрипт на график нужного инструмента, задаете даты и параметр PercentRollback для определения достаточной величины отката. Можете поменять по вкусу настройки блока Visual. По результатат работы скрипта получаете график и файл .сsv с названием типа
Symbol_Period_Recoilless_YYYY-MM-DD-hhmm_YYYY-MM-DD-hhmm.csv в папке ~MQL4Files

А дальше не могу дать рекомендаций. Определяет каждый сам. Я для себя выбираю интересный участок на графике. Что для меня "интересный" участок? Участок в котором ПУ состоит не из одного сегмента. А если еще и Откат не из одного сегмента, то еще лучше. Например, такой как в прикрепленном изображении. Смотрю правильно ли вообще посчитаны минимумы/максимумы, правильна ли общая логика ПУ и Отката. Дальше нахожу этот участок в .csv файле и проверяю данные.


Добавлено.

Взглянув на первые результаты у меня следующие предложения и вопросы. 8-}



Пожалуй, надо вводить какой-то ограничитель для минимального ПУ. Нам ведь не интересно рассматривать "проблемные" участки с величиной проблемы 5-10 пунктов? Или интересно? ;)
На рисунке:
1. AB - ПУ с разницей Min/Max меньше чем ограничительная планка. Но с достаточным откатом BC. Фиксируем в статистике?
2. AD - ограничение пройдено, но откат DE меньше нужного. Фиксируем? А если AB-BC мы зафиксировали, а для участка CD-DE все нормально? Зависит от ответа на 1.
3. AF-FH. Ограничение пройдено. Откат нормальный. Вроде все хорошо, пишем в статистику. Только вот пишем AF-FH или CF-FH? Зависит от ответа на 1.
4. И наконец. Если AB не фиксируем, то где тот момент Z, когда просто забываем про такой "проблемный" участок. ~x( :)

Я в своем скрипте вводил модель (такой же набор входных параметров как в самом боте Setka).
Для участка AB-BC:
Из длинны AB мы знаем кол-во открытых ордеров. Из кол-ва ордеров - знаем процент отката на данном шаге и если он меньше чем BC/AB значит этот участок считаем закрытым и далее рассматриваем участок CD-DE, иначе рассматриваем AD-DE. Ну и так в цикле.

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

Но я вот подумал...
У вас, Oceani4, уже есть чудесный скрипт с изумительной визуализацией.
И вертушка с анализом свечного графика и контролем закрытия сетки по вычисляемому ТР уже есть.
Нет ли смысла сделать/добавить on|off lite режим поиска безоткатных участков, отсекаемых по задаваемому пользователем фиксированному откату в %%?!

А то задача-то не простая, трудно будет верифицировать корректность работы...
И 2 скрипта разных авторов вселили бы уверенность, что мы в анализе опираемся на достоверные и репрезентативные цифры.

[bespaniki]

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

Старик, а что мы хотим получить в конечном итоге? Я что-то запутался уже...
Можно добавить блок параметров для расчета сетки из бота. Долго, муторно, но принципиально ничего сложного. Да, модель саму я буду тогда знать как семинарист "Отче Наш", это плюс. Но что получится в итоге? Упрощенная версия Тестера Стратегий MT4 заточенная под одного бота?

Oceani4, ознакомился с вашим скриптом. Отличная работа! Извините что с опозданием :) Изменено 16 мая, 2018 пользователем bespaniki

[Oceani4]

Спойлер

Спойлер

Коллеги!
Первый ,можно сказать черновой, вариант скрипта для сбора статистики по проблемным участкам для сеток. Пока только по сбору, представлением и прочим займусь тогда, когда удостоверимся что собираем то что нужно, а не мусор всякий ;)

Надо тестировать.
Сначала немного о терминах и о том что на графике по результатам работы скрипта.
"Сегмент" -- участок графика с однонаправленным движением без явных минимумов/максимумов внутри. На графике отображается линией из точек;
"Проблемный участок" (ПУ) -- участок графика с однонаправленным движением, состоящий из одного или нескольких сегментов. На графике отображается сплошной жирной линией;
"Откат" -- участок графика с однонаправленным движением, состоящий из одного или нескольких сегментов, следующий сразу за ПУ в противоположном направлении и разницей между Min и Max не менее чем какой-то определенный процент от разницы Min и Max для ПУ. На графике отображается линией штрихов.

ПУ и откат на графике смещены относительно их действительных значений, для улучшения читаемости. Для long сеток вниз, для short -- вверх. Величина смещения задается. Также можно отключить отображение ПУ+Откат одного типа, установив в "None" цвет.

Теперь о том как тестировать.
Кидаете скрипт на график нужного инструмента, задаете даты и параметр PercentRollback для определения достаточной величины отката. Можете поменять по вкусу настройки блока Visual. По результатат работы скрипта получаете график и файл .сsv с названием типа
Symbol_Period_Recoilless_YYYY-MM-DD-hhmm_YYYY-MM-DD-hhmm.csv в папке ~MQL4Files

А дальше не могу дать рекомендаций. Определяет каждый сам. Я для себя выбираю интересный участок на графике. Что для меня "интересный" участок? Участок в котором ПУ состоит не из одного сегмента. А если еще и Откат не из одного сегмента, то еще лучше. Например, такой как в прикрепленном изображении. Смотрю правильно ли вообще посчитаны минимумы/максимумы, правильна ли общая логика ПУ и Отката. Дальше нахожу этот участок в .csv файле и проверяю данные.


Добавлено.

Взглянув на первые результаты у меня следующие предложения и вопросы. 8-}



Пожалуй, надо вводить какой-то ограничитель для минимального ПУ. Нам ведь не интересно рассматривать "проблемные" участки с величиной проблемы 5-10 пунктов? Или интересно? ;)
На рисунке:
1. AB - ПУ с разницей Min/Max меньше чем ограничительная планка. Но с достаточным откатом BC. Фиксируем в статистике?
2. AD - ограничение пройдено, но откат DE меньше нужного. Фиксируем? А если AB-BC мы зафиксировали, а для участка CD-DE все нормально? Зависит от ответа на 1.
3. AF-FH. Ограничение пройдено. Откат нормальный. Вроде все хорошо, пишем в статистику. Только вот пишем AF-FH или CF-FH? Зависит от ответа на 1.
4. И наконец. Если AB не фиксируем, то где тот момент Z, когда просто забываем про такой "проблемный" участок. ~x( :)

Я в своем скрипте вводил модель (такой же набор входных параметров как в самом боте Setka).
Для участка AB-BC:
Из длинны AB мы знаем кол-во открытых ордеров. Из кол-ва ордеров - знаем процент отката на данном шаге и если он меньше чем BC/AB значит этот участок считаем закрытым и далее рассматриваем участок CD-DE, иначе рассматриваем AD-DE. Ну и так в цикле.

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

Но я вот подумал...
У вас, Oceani4, уже есть чудесный скрипт с изумительной визуализацией.
И вертушка с анализом свечного графика и контролем закрытия сетки по вычисляемому ТР уже есть.
Нет ли смысла сделать/добавить on|off lite режим поиска безоткатных участков, отсекаемых по задаваемому пользователем фиксированному откату в %%?!

А то задача-то не простая, трудно будет верифицировать корректность работы...
И 2 скрипта разных авторов вселили бы уверенность, что мы в анализе опираемся на достоверные и репрезентативные цифры.

Добавил фиксированный откат по %%

В его работе используются 3 параметра:

extern int MinTrend = 300; // Показывать тренды только более MinTrend пунктов на 4-х знаке
extern double MinRollBack = 30; // Минимальный откат в процентах
extern bool lightMode = true; // false - используем модель, true - используем только MinTrend и MinRollBack

+ две вставки в коде (для желающих поковырять код) - стр. 381-383 и стр. 397-399

Логика работы:
дабы не переписывать весь скрипт, то до MinTrend сеток откат считается согласно модели, а вот с MinTrend ( в данном случае от 300 пунктов на 4-х знаке) уже фиксированный % отката. Если поставить MinTrend - 100 пунктов и откат в 30%, то проблемных участков может и не быть - т.к. это параметры ультра агрессивных сетов.

P.S. Скрипт и близко не заменяет советника, он только для быстрого визуального оценивания проблемных участков. Также для разряженных сеток можно увидеть насколько неудачно могут открыться ордера, особенно на старших коленях 13..14..15..

Минипример.
Пусть есть модель - фиксированный шаг 100 пунктов и на каждом шаге расстояние от последнего открыто ордера до TP тоже на каждом шаге - 100 пунктов.
Тогда для сетки в 7 колен получаем % отката 100/700 ~ 14.28%
Но если нам не повезло и у нас открыто 6 колен и до открытия 7-го цена не долетела всего 10 пунктов (вполне жизненная ситуация), то до TP, от точки разворота цены - уже 190 пунктов и % отката в данном случае уже - 190/690 ~ 27,53%

Oceani4_MaxTrend_скрипт_v0.21.mq4

[Старик]

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

Старик, а что мы хотим получить в конечном итоге? Я что-то запутался уже...
Можно добавить блок параметров для расчета сетки из бота. Долго, муторно, но принципиально ничего сложного.
Да, модель саму я буду тогда знать как семинарист "Отче Наш", это плюс.
Но что получится в итоге? Упрощенная версия Тестера Стратегий MT4 заточенная под одного бота?

Нет, упрощенную версию тестера стратегий мт4 для быстрого прогона в максимально жестких (немедленный вход на локальных экстремумах и нулевое растяжение сетки) условиях уже реализовал Oceani4.
И, имхо, сделал очень хорошо - ни прибавить, ни убавить.
Если сет проходит период истории в скрипте Oceani4, при немедленном входе и без влияния фильтров бота - есть высокая вероятность, что с возможностями/влиянием бота сет на этом участке истории должен быть еще устойчивей.
И это уже хорошо сделано - Вам/никому это еще раз делать не надо.

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

1) разрабатываемого вами скрипта или индикатора со статистикой в том виде, что я предлагал - задаваемый пользователем %% отката и таблица статистики выявленных безоткатных участков, закрываемых откатом указанного %. Это без привязки к конкретному сету.
Цель примерно та, о которой вы говорили: путем нескольких прогонов с разными % закрытия (базовый вариант) - получить из статистики:
- представления о возможной длине/длинах сетки и
- оптимальной для сетки данной длины закрываемости в %, близость к которой настройками сета сетки желательно обеспечить.
То есть цель скрипта попробовать получать на разных парах начальное представление о возможных (одной или нескольких) оптимальной длине и закрываемости сетки до начала проектирования сета.
С тем, чтобы проектировать сеты, имея хоть какие-то ориентиры в бесконечном множестве вариантов.

2) скрипт/индюк по озвученной мною идее о замере внутридневной волатильности пары (пробеге цены в пп) на базе зигзага из http://tlap.com/forum/laboratoriya-profitfx/24/open-source-sovetnik-forex-setka-trader-mod-i-ea-setka/2738/?do=findComment&comment=398713
Можно за разные (задаваемые пользователем) периоды вычислячать такие начальные/средние значения:
ДТД - дневной торговый диапазон (по типу ADR?)
ДВП - дневная волатильность (суммарный пробег цены по вертикали) пипсов (можно на базе загзага?)
КДВ - коэффициент дневной волатильности = ДВП/ДТД (чем выше, тем больше пара подходит для мартинов).
Это может оказаться чрезвычайно интересная информация - особенно для дополнительного анализа в эксель и совмещения с графиками.
Например, можно представить себе большую помесячную таблицу из таких троек для множества пар - скажем, с 2014 по сейчас...
Ну очень интересно может оказаться посмотреть корреляцию пар и такую статистику в привязке к графикам пар в периоды трендов, коррекций, консолидаций...
Трудно сказать (маловероятно что) можно ли на основе такой информации создать достаточно точный опережающий индикатор сильных движений цены. И тем более не известно можно ли будет использовать такой индикатор в боте.
Но я не припоминаю, чтобы кто-то эту информацию исследовал - а она может оказаться весьма полезной.


bespaniki, то, что я писал Oceani4, относилось к нему и его скрипту.
Существует системная/стандартная проблема верификации выдаваемой индюками/скриптами информации.
Баги в кодах практически неизбежны, какое-то время нужно на их поиск и устранение и это не так просто.
Потому что если скрипт/индюк содержит хотя бы один баг, по его выдаче/файлу/таблицам часто невозможно понять он работает корректно или его данные полностью или частично искажены багом и фэйковые.
И я заранее беспокоюсь как убедиться в корректной работе вашего будущего скрипта.
Доработка Oceani4, может быть (но полностью не уверен) позволит хоть в какой-то части сверить работу ваших скриптов и получить большую уверенность в корректности их работы.
Ваша же задача никак не менялась: делаете что хотели с начала - с выводом инфы в файл с группированием для заполнения предложенной мной таблицы.

[bespaniki]

Ок! Ждем тогда результатов тестирования первой версии.
Активнее, коллеги! Пару мелких багов я уже сам нашел. :)

[Oleg Snegov]

Добрый вечер, коллеги

2) скрипт/индюк по озвученной мною идее о замере внутридневной волатильности пары (пробеге цены в пп) на базе зигзага из http://tlap.com/forum/laboratoriya-profitfx/24/open-source-sovetnik-forex-setka-trader-mod-i-ea-setka/2738/?do=findComment&comment=398713
Можно за разные (задаваемые пользователем) периоды вычислячать такие начальные/средние значения:
ДТД - дневной торговый диапазон (по типу ADR?)
ДВП - дневная волатильность (суммарный пробег цены по вертикали) пипсов (можно на базе загзага?)
КДВ - коэффициент дневной волатильности = ДВП/ДТД (чем выше, тем больше пара подходит для мартинов).

Попробовал такое нарисовать. Надеюсь, что недопонял немного. В приложении скрипт и его проверка. Взял период GBPUSD 01.05.2018 - 10.05.2018 00:00, 10 мая в расчет не входило, всего 7 дней.

В табличке Exel отдельно выписал ATR для каждой свечи D1, на H1 нарисовал зигзаг и выписал в табличку все его значения. Соответственно все подсчитал - средний ATR и пробег цены между вершинками зигзага. На границе диапазона за крайние точки отсчета взял цену открытия 01.05 и цену открытия 10.05 (она же цена закрытия 09.05), т.е. первый пробег цены слева на графике = (открытие 01.05 - первый зигзаг слева (1.35796)), который был в 09:00 02.05. Все аналогично справа.

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

VolZZ.xlsx
VolRes.png
ZZRes.png
ZZ_Vol.mq4

Изменено 17 мая, 2018 пользователем Oleg Snegov

[Старик]

Oleg Snegov, очень рад, что вы взялись за проработку этого вопроса! :)
Вопрос, возможно, весьма глубокий и не исключаю, что в этом направлении нам придется поработать достаточно долго, разработать много разных форм/сводок для анализа - может, еще и с привлечением спецов по экселю.

Первый подход у вас вышел пристрелочный. :)
Индикатор ATR, горячо любимый многими, я не очень люблю совсем и в моем тексте он не упоминался ни разу.
Может, я недопонимаю ATR и он отвечает мне взаимностью...
я упоминал индикатор ADR (Average Daily Range) http://tradelikeapro.ru/foreks-indikator-adr/ - а это совсем другая история.
Так что интересующих меня цифр я пока не увидел даже в первом приближении, а вам придется глубоко переработать скрипт.

Общий подход, которого я пытаюсь придерживаться в этом проекте - это работа только с первичной информацией.
У нас есть график движения цены, есть время движения цены - и есть порции этого свечи.
Мы фиксируем и анализируем только первичную информацию - по возможности не используя ничего, кроме арифметики и абсолютного минимума индикаторов.
Потому что чем меньше чужих инструментов в нашем анализе - тем достовернее выводы, которые мы можем получить.
Не факт, что мы сможем получить какие-то бесценные выводы и войти в историю Форекс.
Но мы пробуем изучать применительно к мартинам то, что возможно до нас изучено не было, и получить достоверную информацию, которая может дать нам указание как наиболее оптимально мартинами торговать.

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

Ну и из этого понятно, что ДТД (абсолютное значение [хай-лоу] дня) и ДВП (сумма абсолютных/положительных значений проекций расстояний между вершинами загзага по вертикали внутри дня|интервала) измеряются в пипсах и всегда положительны.
А коэффициент КДВ=ДВП/ДТД всегда положительно число >1. И чем КДВ больше, тем пара внутри дня волатильнее и, вероятно, интереснее для мартинов.

Имхо, м5 максимальный ТФ, с которого можно брать инфу о вершинах предположительно стандартного зигзага.
ТФ уровня Н1 поглощает/скрывает слишком много движения цены, отлично читаемого и используемого ботом.

Спойлер

Даже на м5 из учета выпадут 2 шипа (белые стрелки) в 60-70 пипсов движения цены при том, что минимум один из 2-х шипов мог закрыть небольшую сетку по ТР.
Видимо, м1 слишком шумный для анализа - зигзагом будет учитываться слишком много бесполезного в торгах микродвижения цены.
Но на больших м5 (м15?) ТФ видимое и торгуемое ботом движение цены заглаживается и инфа о внутридневной волатильности утрачивает достоверность.

Имхо, нам может понадобится в настройках задавать ТФ зигзага - ну или жестко текущий ТФ графика.
И, если будет использоваться стандартный зигзаг или его самописный аналог или один из великого множества его вариантов, все настройки индикатора зигзаг стоит вывести в параметры скрипта.
Кто ж его знает какие настройки зигзага для какого ТФ (для какой пары?) окажутся оптимальными...

Также, имхо, в скрипте стоит иметь возможность выборки/обработки информации:
1) по дням недели, on|off понедельник, вторник, среда... По дефолту учитываем все дни недели.
2) один интервал внутри дня, с часа Х по час У включительно. По дефолту 00 и 23, т.е. анализируем сутки целиком.
Вряд ли это будут широко используемые опции и может те же дни недели и в эксель выбрать было бы можно.
Но пусть лучше такие возможности будут в скрипте от начала разработки, когда-то могут понадобится.

Ну и на сегодня последнее, что попонимаем - надо принять решение как фиксировать первый и последний участки внутри дня или внутри внутридневного интервала.
Крайне маловероятно (почти никогда), чтобы вершины зигзага всегда приходились на первую/последнюю свечу начала/конца дня или внутридневного интервала.
Почти всегда предыдущая вершина зигзага хронологически до начала (первой свечи) дня/интервала, а первая вершина зигзага вне/после дня/интервала после завершения времени дня/интервала.
То есть у первой и последней вершин зигзага внутри дня/интервала нет одной из 2-х смежных вершин зигзага: у первой нет слева - у последней нет справа.
Вдобавок ко всему у многих ДЦ полночь приходится на ролловер, известный шипами и вообще не торгуемый в ряде ДЦ.

В связи с этим выглядит обоснованным такое предложение:
1) первый внутри дня/интервала участок отмерять от open первой свечи дня/интервала до первой слева вершины зигзага внутри дня/интервала
2) последний внутри дня/интервала участок отмерять от последней справа вершины зигзага внутри дня/интервала до close последней свечи дня/интервала.
Надеюсь, что такой подход достаточно строг и внесет совсем минимальные искажения в статистику.

Вывод информации в файл можно организовать по той же схеме, что применяется коллегами в разработке контроля просадки в мультивалютных тестах.
Структура записи файла в первом приближении может быть такой:
1) символ
2) дата ГГГГММДД с или без разделяющих точек или тире
3) первый час внутридневного диапазона. Дефолтно 00 - с открытия суток
4) последний час внутридневного диапазона. Дефолтно 23 - до последней минуты суток включительно.
5) день недели - 1, 2, 3, 4, 5
6) ДТД целочисленное (пипсы) - всегда абсолютное значение (хай-лоу) дня
7) ДВП целочисленное (пипсы) - сумма за весь день или выбранный интервал времени внутри дня
8) КДВ с округлением до 3-х знаков после запятой.

По собственно скрипту вроде в основном всё.
Остальное надо начинать думать с нуля и не в 5 утра. :)


P.S. В принципе, я совершенно не против, в дополнение в вышеперечисленной минимальной информации о волатильности, параллельно собирать и даже записывать в файл для последующей обработки информацию от каких-то других индикаторов.
То есть если кто-то считает, что будет полезным параллельно с накапливанием информации о волатильности, фиксировать и сохранять в файл показатели того же ATR и/или других индикаторов, то ради Бога!
Наверно, настройки других индикаторов тоже надо выносить в настройки скрипта.
Но, в принципе, профессионально за один проход графика собирать/фиксировать максимум информации с целью последующего анализа.


Коллега Oleg Snegov - успехов! :) Изменено 19 мая, 2018 пользователем Старик

[Старик]

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

В моде от Igor731 примерно так и происходит, но с небольшими отличиями:
просадка считается каждый тик и сравнивается с просадкой на предыдущем тике. Если она больше, то запоминается.
1 раз в заданный период (по умолчанию D1) значение (максимальной за период) просадки записывается в массив, которой в итоге скидывается на диск. Период можно задать и М5, но за значимый промежуток времени тестирования получится нехилый массив, который вкупе с несколькими парами затруднит дальнейший анализ.
Вообще, метод все равно дает погрешность по большинству пар за счет разной стоимости тика на истории...

Всегда стараюсь не мешать людям изучать вопросы и прощупывать какие-то возможности.
Но, боюсь, что данная доработка так легко из ордер в неделю вабанка в лютые мульти торги мартинами не переносится.
Коллеги usver73, chinch19, Igor731, dkfcnm - давайте чуть со стороны, в общем, на прорабатываемую технологию глянем...

Если в анализе не используется понятие депо в деньгах, этот вопрос снимается

Чисто формально надо отметить, что в мультиторгах всё равно контролируется обычно 2 депо - отдельных пар и их совокупности на счете.
Стоп в отдельных парах выставляется обычно с учетом расчетного депо каждой пары порознь.
При этом больше всего нас интересует суммарная просадка мультиторгов применительно к депо мультиторгов.
Надо ли подумать нет ли в анализе в эксель какого-то конфликта/непоняток между множеством чисел депо разных пар и общим/меньшим депо для мультиторгов и всегда ли можно опираться (достаточно ли?) только на одно число депо мультиторгов?
Но если в текущей реализации оценки/анализа совокупной просадки в мультитестах в эксель нет понятия/параметра депо любого типа как такового, то тогда мой вопрос беспредметен и снимается.

Если в анализе просадок у вас есть и доступна инфа о количестве колен, вопрос снимается

Далее, есть ли возможность понимать из каких пар суммарная просадка формируется и, возможно, и сколько колен открыто в каждой сетке при большой суммарной просадке?
Запоминать и визуализировать это как-то или отсылать в тестах искать где сколько было колен в просадке на конкретную дату в тестах все пар?
Ну нашли мы 30 или 50 дат с суммарной просадкой, с которой надо разбиратся, в 3-хлетнем мультитесте - что с этим делать?
Стейтмент тестера комментариев ордеров не содержит, даже если руками рыться в стэйтментах, еще и модели всех сетов нужны, чтобы по лотности ордеров из стейтмента узнать сколько колен в какой паре было...
я сильно не разбирался в том что вы делаете, да и работаете вы в режиме страшно секретного завода.
но первое впечатление даже думать об анализе просадки без инфы о количестве колен по парам неудобно, а уж регулярно такой анализ делать даже непонятно как...
Имхо, сохранять инфу о количестве колен в парах при оценке (в момент) просадки мультиторгов крайне желательно.
Надо подумать и над удобством технологии имитации мультиторгов в тестере спратегий и последующей обработке и визуализации результатов...
Но если информация о количествах колен в момент просадки в статистике суммарной просадки имеется и она доступна при анализе, то вы уже решили вопрос, который мне кажется проблемным.

-----

Далее, сетки из-за существенной лотности обладают огромным потенциалом и чрезвычайной волатильностью/динамикой просадки.
При этом даже в моих условно агрессивных сетах присадка растет в %% от депо поначалу медленно, но рост экспоненциальный.
В итоге коммулятивный эффект сумм просадок сеток в мультиторгах очень существенный и динамика изменения просадки внутри дня может быть очень высока.
В торгах реально был случай, когда по 14 колен открылось и закрылось в один день в 2-х парах - но депо это ни разу не напрягло, так как вторая сетка доразвернулась до 14 колен после того, как развернулась и закрылась по ТР первая.
Динамика просадки в этот день была просто просто сумашедшая.
Но важнее то, что при фиксации пиковой просадки раз в день, возможно, совмещенный тест показал бы слив или завышенные требования к депо для мультиторгов.
Имхо, при мультиторгах высоколотными сетками фикс просадки раз в день неприемлем - слишком много движения укладывается в один день.
Возможно, таких дней не очень много, но просто суммирование асинхронных посадок внутри дня в какие-то дни слишком грубо.

Боюсь, что myfxbookовские 5-минутки именно то, что надо для объективного контроля просадки в мультиторгах. Ну может м15.
Не факт, что контроль просадки на уровне м5/м15 будет нужен во всех или большинстве имитаций мультиторгов в тестах - наверно, в большинстве тестов и посуточного контроля просадки будет достаточно.
Но, по крайней мере, разрабатываемый вами контоль просадки в мультиторгах должен быть готов иногда работать и с м5/м15 инфой.

Но это означает формирование огромного файла статы просадки по нескольким парам.
При этом 90%+, а может и 95%+ инфы в этом файле будет заведомо реально бесполезной, так как будет содержать инфу о де-факто отсутствующей или (даже в сумме) не представляюще интереса низкой просадке.
Обрабатывать такие массивы инфы в эксель невозможно или неудобно или очень долго.

Для фильтрации информации о просадках м5/м15 детализации и сохранения лишь значимой информации о просадках напрашивается написание вроде достаточно понятного скрипта.
Напрашивается считывание и синхронизация записанной ботом в тестах в файл м5/м15 информации о просадках, промежуточное суммирование синхронизированных просадок всех пар - и обработка в зависимости от выбранного режима.
Имхо, режимов работы этого скрипта может быть 3.

1) информационный.
Вычитывается весь сгенерированный ботом файл м5/м15 просадок, информация о просадках на разных парах синхронизируется и выдается справка произвольной формы о скажем 3-х наибольших просадках в тесте.
Дата, время, количество buy или sell колен в парах - просто чтобы человек мог увидеть основные узкие места и продолжить работу с проблемными сетами, минуя использование расширенного анализа.
Новый файл в этом режиме не создается, имеющийся файл бота не пересоздается и не модифицируется.

2) трансформация файла бота о просадках из уровня детализации м5/м15 в D1.
Вычитывается весь сгенерированный ботом файл м5/м15 просадок, информация о просадках на разных парах синхронизируется, посуточно вычисляется инфа о максимальной просадке (с сохранением инфы о количестве бай/селл колен) и D1 инфа о просадках выводится в файл той же структуры, что генерировался бы ботом на D1 ТФ.
Файл бота можно перезаписать заново (если ботом будет генерироваться единственный файл), иначе создать новый (единый?) файл просадок D1.

3) сохранение инфы о просадках детализации м5/м15, но отсечение всей инфы о сумарной просадке ниже задаваемой суммы (или задаваемого в % уровня для задаваемого депо мультиторгов).
Если задачей скрипта будет лишь в 10-20 раз усушить/сжать файл с инфой о просадках в мультиторгах, то тогда сжимающий скрипт может формировать файл той же структуры, что и основной после формирования ботом, но для ТФ м5/м15.
Но такой файл будет содержать не сквозную инфу за весь анализируемый период, а лишь о периодах просадки выше минимально допустимой/ничтожной.
Считывается весь сгенерированный ботом файл м5/м15 просадок, информация о просадках на разных парах синхронизируется, вычисляется инфа об м5/м15 просадке (с сохранением инфы о количестве бай/селл колен) и в файл выводится лишь инфа о периодах просадки большей, чем задана в настройках.

-----

Ну и, в определенном смысле, узким местом вашей технологии есть формирование модом бота единственного файла просадок всех пар - судя по имеющейся на сейчас у меня информации.
Понятно, почему так сделано - так проще подавать информацию в эксель для формирования сводок.
но, поскольку это простейший последовательный файл, это крайне неудобно для пользователя - формирование файла просадок отнимает много времени и требует последовательного бесполезного повторения действий, в ходе которых пользователь может многократно ошибиться.
Ведь при шлифовке сетов и многократном мультитестировании, наскольно понимаю, формирование единого последовательного файла просадок требует повторных тестов всех пар, участвующих в мультиторгах. То есть вы вносите изменение в сет 1 пары, а надо снова и снова выполнять ретест всех пар планируемых мультиторгов. Так как новая инфа в старых/повторяющихся тестах не создается, это бессмысленная/паразитная нагрузка.

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

-----

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

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

[chinchi19]

Так что лучше я свои сомнения и предложения заранее выложу.:)

Коллеги! Краткая информация по создаваемому инструменту теста мультиторогов нашим ботом.

1. Бот пишет информацию по паре в режимах: а) одиночного теста пары; б) группового, последовательного теста пар входящих в портфель. Штатными функциями Эксель одиночные тесты можно "сшивать" в группу тестов. Так, что здесь трейдер свободен в принятии решения.

2. Бот может писать в файл на любом ТФ по выбору трейдера. Хоть на минутках можно рассматривать в микроскоп Просадку+маржа, колен, прибыль за период. Трейдер свободен в решении, как настроить бота.
С какой точностью смотреть на эти данные зависит только от трейдера и возможностей его железа.

ТФ Д1 считаю самым наилучшим решением для теста и вот почему. Сугубо мое мнение - если просадка разнеслась на несколько часов и депо уцелел, то трейдеру просто сказочно повезло. По мне лучше иметь данные "предупреждающие" о возможной просадке. Предупрежден, значит вооружен.

3. Секретности абсолютно нет никакой. Хоть чуть-чуть причешем Эксель-анализ и ВСЕ МАТЕРИАЛЫ на форум выложим. 2 версии бота, 2 версии Эксель -анализа результатов тестов. Инструкции, как пользоваться и ботом и Эксель анализом.

4. Достоверные данные тестов могут быть получены, на сейчас, за весьма ограниченный период времени. Связано это с тем, что в предыдущие периоды цена пипса и маржа меняются в значительных пределах. Есть просьба к форумчанам - сделать таблицу в эксель велечины пипса и маржи за период с 2010 года, для начала хоть одной пары. Имея такую таблицу в эксель, можно ввести поправочные коэффиценты с помощью которых можно откорректировать данные теста и достоверность анализа на истории будет повышена.

5. Наш программист ИГОРЬ731 не сможет дальше участвовать в дальнейшей модификации бота для мультиторгов. Я очень ему благодарен за то, что уже сделал и желаю ему успеха во всех его делах. Может, кому-то будет интересно поучаствовать в дальнейшей модификации бота для теста мультиторгов, напишите в личку, все обсудим!

С уважением, Изменено 20 мая, 2018 пользователем chinch19

[Старик]

Коллега usver73, наконец-то мне удалось выписать все соображения по обсуждавшимися вами и мной индикаторам.
Даже не понимаю почему так долго у меня это не получалось - ну не мог сконцентрироваться и выписать никак, правил и переписывал... :"> :)
Очень жаль, что так долго писал!...

Ну и все же считаю правильным ответить вам не в личку (где мы рабочие вопросы можем продолжить обсуждать), а опубликовать в топике.
Есть надежда, что кто-то из опытных коллега пару замечаний/предложений к моему посту добавит.

-----

Спойлер

Созреваем для продолжения развития проекта :)

Посмотрите, пожалуйста http://tlap.com/forum/laboratoriya-profitfx/24/open-source-sovetnik-forex-setka-trader-mod-i-eaqj-setka/2738/?do=findComment&comment=388164

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

Приветствую!
Работу по мере сил буду продолжать, но сейчас есть сложности с техникой и временем.
И сразу вопросы:

Цитата

новый индикатор CandlesGroupAverageStatistic - усредненная статистика групп из 2-7 свечей (задается в настройках) подряд.
Это развитие уже созданного индикатора AverageStatistic (CandlesSingleAverageStatistic): абсолютно те же 2 таблицы

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

Нет, я невнятно сформулировал по CandlesGroupAverageStatistic как развития AverageStatistic (CandlesSingleAverageStatistic).
Насколько понимаю, в новом индикаторе можно вообще не менять блок визуализации на экране и схему вывода в файл - что и как выводится в AverageStatistic 1.7.1 (CandlesSingleAverageStatistic), так же может выводиться и в CandlesGroupAverageStatistic.
Отличие только в совершенно другом блоке анализа свечей: вместо единичных свечей - поиск групп Х свечей подряд и формирование статистики таких групп свечей.
Но визуально, имхо, вывод на экран можно оставить тот же, что и в уже имеющемся AverageStatistic 1.7.1 (CandlesSingleAverageStatistic).

А вот с CandlesSingleDistributionStatistic и CandlesGroupDistributionStatistic ситуация обратная.
я надеюсь, что детализация по дням недели всё же излишняя - мы не планируем делать разные настройки фильтра волатильности/спрэда/входа в зависимости от дня недели, да и руками вряд ли кто-то будет ежедневно чуть-чуть изменять настройки фильтров.
Кроме того, новая таблица шире и длиннее и вам вряд ли удастся поместить на экран много больших по размеру таблиц.
Именно поэтому я и ограничился предложением только 2-х таблиц на экране максимум (круглосуточной и внутридневной выборки) без детализации по дням недели.

Но, в принципе, это вопрос на ваше усмотрение.
Какие выборки делать/обсчитывать и что визуализировать - это 2 разных вопроса.
Если вам будет удобно накапливать и обрабатывать информацию еще и по дням недели раздельно, то я от этого вас отговаривать не буду. :)
Такую информацию по дням недели раздельно можно было бы выводить только в файл, откуда её могли бы копировать особо любознательные и вставлять в безхитросные таблицы эксель.

Имхо, в CandlesSingleDistributionStatistic и CandlesGroupDistributionStatistic достаточно вычисления и визуализации только 2-х сводных итоговых таблиц без детализации по дням недели.
Но если вы решите сделать еще и детализацию по дням недели с выводом информации по дням недели только в файл, то вас за это точно никто не осудит и позднее это инфа могла бы и пригодиться для более детального анализа.

Вообще, на мой взгляд, DistributionStatistic окажется на порядок важнее AverageStatistic - усредненная статистика, даже с разбивкой по дням, даёт слишком обобщенную информацию.
А вот распределение/частота единичных и групп свечей по длинам, скорее всего, даст нам критично недостающую инфу для фильтра волатильности как минимум - и мы сможем эксклюзивно точно настроить бота на каждую валютную пару.
Да и для блока безиндикаторного входа я жду точные настройки именно от DistributionStatistic...

2. Допустим, анализируем группу из 5 свечей. Период- 1 час, ТФ= М1. Значит анализ начинается с 55-й свечи, т.е. в результат войдет 55 групп свечей. Я правильно понимаю?

А вот х.з....
Пример периода 1 час не вполне жизненный и, имхо, несколько искажает то, как (имхо) надо делать выборку.
Давайте возьмем период хотя бы 2 часа - этот пример корректен и для больших периодов выборки.
В этом случае у нас 2 варианта выборки - первый час периода выборки и второй и последующие часы периода выборки.

Первый час периода выборки (который может быть и первым часом суток) вряд ли стоит анализировать, учитывая минуты предшествующего часа.
Первый (тем более единственный) час периода выборки (и первый час суток?), скорее, можно начинать анализировать лишь по первым 5 минутам этого же первого часа.
И да, в первом часе периода выборки получается вроде 55 групп свечей.

Иное дело второй и последующие часы периода выборки (и суток?) - здесь анализ возможен от первой до последней минут часа с учетом нескольких минут предыдущего часа.
Во втором и последующих часах периода выборки вроде 60 групп свечей.
Верно же?!


P.S. В предлагаемые названия индикаторов я в конце добавил вообще-то не нужную "S" :">
Фиг его знает зачем, по смыслу вроде и не нужна. Но переклинило меня тогда с этим "S" в конце.
Предлагаю в названиях индикаторов вроде лишнюю "S" всё же не использовать, в этом посте я её поудалял. :)

-----

Но есть еще несколько усложняющих нюансов:

1) в таблицах будущих индикаторов СandlesSingleDistributionStatistic и CandlesGroupDistributionStatistic в первом/левом столбце "Длина свечи, пипсов" шаг нужно задать переменный и задаваемый пользователем.
В таблице с образцом шапки я недоделал эту часть - поторопился выложить гигантский пост 22000+ символов, очень уж меня этот пост достал.
Количество строк с информацией о свечах в таблице может/должно быть фиксированным типа 15+-2-3 строк. Это зависит от того какие максимальные размеры таблиц вы сможете вывести на экран.
Но вот шаг (шкала) в пипсах должен учитывать и разрядность (4/5 и 2/3 знак), и дискретность - имхо, шаг как-то должен напрямую задаваться пользователем в настройках. Вот это я в образце таблицы не отметил, хотел но не сделал.

Это где-то проблема, что для разных пар, разных ТФ и разных разрядностей шкалы могут очень отличаться.
Например, для тихоходной тяжелой eurusd на м1 4-х знак шкала может быть от 0 с шагом 1 пипс, максимум 2 пипса.
Для быстрых же gbpjpy или gbpchf на м1 5-тизнак шкала может понадобится от 0 с шагом 50 пунктов (5 пипсов 4-хзнак).
То есть если в таблицах будет (например) жестко 15 строк, то, согласно примеров:
- для eurusd шкала будет от 0 до 14 или 28 (с шагом 1 или 2),
- а для gbpjpy или gbpchf будет шкала от 0 до 700 (с шагом 50).

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

-----

2) свечи с нулевыми размерами (телами и даже тенями/ногами) - их очень много на счетах с фиксированными спрэдом.
Под них нужна, как минимум, отдельная строка в таблицах CandlesSingleDistributionStatistic.
[а может и две строки (нулевые тела и тени и нулевые тела + ненулевые тени/тень, ноги, хвосты?...). С этим мне не вполне понятно - как думаете?]

Вдобавок ко всему свечи с нулевым телом (с нулевыми и не нулевыми тенями) в CandlesSingleDistributionStatistic нельзя отнести ни к бай, ни к селл - в общем числе свечей они есть, а в бай/селл раздельно учесть невозможно ввиду невозможности определить их пол из-за отсутствия тела.
Поэтому в строках свечей с нулевым размером может быть указано только общее количество таких свечей без разбивки на бай и сэлл (и, выходит, в этой строке 0% в столбцах бай и селл свечей, что неизбежно несколько исказит статистику выборок бай и селл свечей). Может быть, что даже сумма % будет не равна 100% в каких-то случаях?
А вот в этой же строке в столбцах без разбивки на бай и сэлл распределение по длинам в %% будет корректным, а сумма %% = 100%.

-----

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

Группы из не учитываемых повторно свечей в смежных группах, несомненно, более строгий и формальный вариант, точнее отражающий реальный график.
Например, 4-е однонаправленных свечи подряд в этом случае образуют/учитывается как:
- 2 группы из 2-х свечей (1-2 и 3-4),
- 1 группа из 3-х свечей (1-3) и
- 1 группа из 4-х свечей.
И теоретически именно так вроде и надо бы формировать/учитывать группы свечей, чтобы статистически достоверно учесть группы свечей на графике пары.

но торги и бот требуют иного - нам надо знать сколько раз на графике были свечные комбинации, отвечающие условиям для открытия первого ордера.
И такой прикладной подход к анализу свечного графика спокойно допускает, что одна свеча может даже 2-3 раза учитываться в смежных группах свечей.
Например, 4-е однонаправленных свечи подряд в этом случае образуют/учитывается как:
- 3 группы из 2-х свечей (1-2, 2-3 и 3-4),
- 2 группы из 3-х свечей (1-3 и 2-4) и
- 1 группа из 4-х свечей.

Идеально было бы реализовать оба варианта вхождения/учета свечей в группах свечей - но это может быть сложно.
Первоочередным же для поддержки работы бота является второй вариант, при котором свеча может входить более чем в одну смежные, частично пересекающиеся/накладывающиеся группы свечей.
Но для множества других проектов/ТС, в которых разрабатываемые вами индикаторы могут стать решающим/ключевым инструментом анализа, нужен и первый (без повторений) вариант учета вхождения свечей в группы.
В общем, я бы вам рекомендовал очень хорошо это обдумать и:
- сначала реализовать (второй) вариант для бота
- но потом реализовать и оба (+первый) варианта для использования в разработках ТС/ботов во множестве других проектов.

-----

4) надо определиться как накапливать инфу о свечах по строкам размера свечей.
Вопрос не вполне однозначный как бы и, возможно, и достаточно серьезный - надо сделать по уму...
Например, в таблице (левый столбец) пользователь задал шкалу длин свечей 0-10-20-30-40... Это как бы простой вариант - аналог 4-хзначной шкалы с шагом 1 (0-1-2-3-4...) для 5-тизначного счета.
Однако 5-тизначные свечи могут иметь не точно совпадающие со шкалой размеры - например, 7 или 12 пунктов.
И надо выработать алгоритм отнесения свечей, не точно совпадающих со шкалой размеров свечей, к каким-то строкам итоговых таблиц.
Причем алгоритм должен быть достаточно универсальным, чтобы корректно работать на разных шкалах и для счетов с разным/любым количеством знаков после точки/запятой.

В общем случае можно применять подход обычного округления - свечи с последними цифрами 5,6,7,8,9,0,1,2,3,4 учитываются в строке с 0 между ними.
То есть свечи с длиной 15, 17, и 24 должны учитываться в строке 20 - если шаг таблицы 10 и строки 0-10-20-30-40...
Но шаг таблицы может быть любой - и 2, и 3, и 15 и надо, чтобы в любом случае свечи разной длинны осмысленно "притягивались"/учитывались в строках таблицы.

Можно искать "свою" строку свечи в таблице, ориентируясь на 1/2 шага с минимальной привязкой к конкретным цифрам.
Например, шаг строк в таблице 15: полшага 7.5 - с округлением 8.
Тогда свеча относится к (учитывается в) строке с учетом полушага: снизу (от значения строки минусуем полшага, например 45-8) по больше или равно - сверху (плюсуем, например 45+8) по строго меньше.
То есть свеча с длинной Х, удовлетворяющая условию 45-8
Однако и такой более универсальный подход может не очень хорошо работать в таблицах с узким шагом 2 и 3.
Скорее всего, придятся применять несколько разных алгоритмов - для шага 2, для шага 3 и для шага больше 3 (имхо, далее применять полушаг).
Первые 2 алгоритма для шагов 2 и 3, скорее всего, жестко прописанные - а с шага 4 с вычислением и применением полушага.

Еще один возможный вариант привязки/определения в какую строку сводки записывать инфу о свече/группе_свечей согласно их длины в пипсах, можно посмотреть в моем предложении по скрипту статистики "безоткатных" участков, разрабатываемого коллегой bespaniki.

Спойлер

Есть пожелание по каждой анализируемой паре выдавать таблицу со статистикой выявленных однонаправленных участков - вместе и раздельно long и short.
В файл csv таблицу писать для визуализации в экселе или пытаться на экран вывести - то другая тема, можно подумать в зависимости от того какой объем инфы будет формироваться и выводится.
Возможно, что лучше готовить/выводить данные таблицы в файле для экселя и в экселе результаты анализа и смотреть.

Имхо, стоит задать шкалу длин проблемных участков (по вертикали) - до 100пп и с (задаваемым) шагом 20-30(?) пипсов от 100+шаг до длины максимального проблемного участка, выявленного в ходе анализа.
То есть если шаг 20, то:
- в строке 100пп учитываются все завершенные "проблемные" участки длиной по 100 пипсов ровно включительно
- а в смежной строке таблицы 120 пп учитываются завершенные "проблемные" участки длиной от 101 по 120 пипсов ровно включительно
- и так, строка за строкой с шагом 20, таблица формируется до наибольшего выявленного завершенного "проблемного" участка графика, который в единственном экземпляре может быть учтен в таблице в строке 640пп или 860пп, например.

В каждой строке таблицы (т.е. по каждому диапазону) по минимуму можно вычислять (вместе и раздельно long и short):
1) количество выявленных "проблемных" участков длины, входящей в диапазон строки
2) %% от общего количества выявленных в ходе анализа "проблемных" участков разной длины
3? средняя длина "проблемного" участка данного диапазона - сумма длин, деленная на количество.
Не факт, что 3? будет очень полезной инфой, но такой вычисляемый показатель может оказаться полезным при верификации работы скрипта (или индюка) - так как может подсказать нет ли ошибок при заполнении таблицы согласно заданных шага и диапазонов.

То есть получается таблица:
- с переменным количеством строк, зависит от длины самого длинного "проблемного" участка и задаваемого пользователем шага
- с 10 колонками - в одной выводится диапазон и 3 блока по 3 столбца итоговой инфы об участках вместе + раздельно long и short

Возможно, и в ваших индикаторах можно реализовать такой подход к привязке длин свечей/групп_свечей к заданному пользователем шагу таблицы визуализации результатов анализа длин свечей.
Меня, в принципе, устраивает оба подхода - вроде оба в среднем (при разумном шаге таблицы) позволяют получить репрезентативную статистику длин свечей для анализа в практических торгах.
Подумайте как вам будет удобнее это сделать.
Можем подумать/поговорить об этом еще.
но, имхо, вы можете из предложенных выбрать на ваш взгляд лучший вариант привязки/визуализации и реализовать его на своё усмотрение.
Важно только ясно пояснить как длины свечей/групп_свечей учтены/отображены в формируемых вашими индикаторами таблицах.

-----

5) Намного сложнее обработка свечей с нулевыми телами/тенями в индикаторах групп свечей.
Эта тема в боте уже реализована в блоке безиндикаторного входа на, имхо, приемлемом уровне - так что можете посмотреть соответствующий код.
Но вопрос довольно скользкий и нам стоит письменно еще раз подумать об этом.

Давайте в данном подпункте для краткости записи обозначать свечи с нулевым телом (open=close) нулем.
Нулевых свечей обычно очень много ночью и вечером на графиках м1 и даже м5 - особенно на 4-х и даже 5-ти значных счетах с фиксированым спрэдом.
Так что их осмысленная обработка реальная необходимость и отнюдь не надуманная проблема.

Есть условный консенсус в том, чтобы внутри искомой группы (!!) из Х свечей считать нулевые свечи справа свечами продолжения направления.
То есть свечи buy-0-0-sell можно/следует интерпретировать как 3buy(buy-buy-buy)-1sell.
И, если вы ищете группы из 2-х или 3-х свечей, то buy группу вы нашли и её данные надо запоминать для последующего анализа.
Это, конечно, условно - но это все же логичнее, чем считать следующую справа нулевую свечу (без направления) свечой встречного направления.
Имхо, при анализе групп свечей, если 1-2 свечи определили buy|sell направление группы, считать последующие нулевые свечи движением в том же направлении вроде как логично.

Получается, что запоминаемая в статистике группа свечей не может состоять только из нулевых свечей.
То есть если искомая группа Х свечей вашим индикатором найдена и в статистику записана, то все правее подряд нулевые свечи сами по себе группу образовать не могут ввиду отсутствия признака buy|sell направления.
То есть все идучие подряд, вслед за группой Х свечей, нулевые свечи, выходит, надо пропускать...

Ну и тогда выглядит логичным, что группа свечей может начинаться со свечи только с не нулевым телом.
Это позволит вам определить buy|sell направление искомой группы свечей - если эта свеча не единственная по направлению.
Ну а если следующая свеча встречная, то buy|sell направление искомой группы свечей меняется - но всё равно первая свеча группы с не нулевым телом.

Вроде всё логично и рассмотрены все случаи... Согласны?

-----

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

-----

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

Попробуйте найти время и силы для качественной реализации обсуждаемых индикаторов! :)
Я практически на 100% уверен, что они "пойдут в народ" и найдут применение во многих ТС.

[DENYA]

Кто о чем, а я все продолжаю эксперименты. Дело это не благодарное, Эдиссон например выполнил 10 000 экспериментов прежде чем найти вариант лампочки сгорания, которая не перегорала бы сразу после включения. 10000!

ЭКСПЕРИМЕНТ:
Поиск сета с принудительным стопом по определенной просадке, желательно маленькой просадке. Большого количества ордеров, с маленьким шагом и, как следствие, не большим мультом.

Видно ЯВНО выраженное движение депозита в сторону увеличения. Любителям КАНАЛОВ рост баланса напоминает движение цены в канале. Также видны периоды стагнации, иногда по несколько месяцев. (пока меня именно такие периоды и отпугивают от подобных типов сетов).
Такой сет способен с 400$ первоначального баланса и удачного СТАРТА (чтобы сразу не попасть на стоп по просадке) увеличится за 2.4 года до 25 400$, или в 63раза, что вполне неплохо ...

Сет [Setka1.43][EURUSD M1][2016.01.04-2018.05.04][DD400 ][K5.53][Grid4,Mult1.2,TP65,Corr2][SetType:DD-A1] получился вполне удачным. Делаю вывод что РАЗВИВАТЬ сеты в область "безопасных сеток" можно и нужно. Данное направление имеет слабое место - долгая стагнация баланса счета, НО считаю такой тип сетов гораздо безопаснее традиционных сетов БЕЗ ограничений по просадке ....

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

Setka1.43EURUSD_M12016.01.04-2018.05.04DD400_K5.53Grid4Mult1.2TP65Corr2SetTypeDDA1.png
Setka1.43EURUSD_M12016.01.04-2018.05.04DD400_K5.53Grid4Mult1.2TP65Corr2SetTypeDD-A1.set

[RomanR]

Такой сет способен с 400$ первоначального баланса и удачного СТАРТА (чтобы сразу не попасть на стоп по просадке)

Приветствую! Чтобы увеличить наши шансы удачного СТАРТА предлагаю оптить полученный сет в советнике с индикаторным входом первых ордеров - [EA] - Setka v1.43 RSI-CCI.

[maxand]

Делаю вывод что РАЗВИВАТЬ сеты в область "безопасных сеток" можно и нужно. Данное направление имеет слабое место - долгая стагнация баланса счета, НО считаю такой тип сетов гораздо безопаснее традиционных сетов БЕЗ ограничений по просадке ....

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

[chinchi19]

Данное направление имеет слабое место - долгая стагнация баланса счета, НО считаю такой тип сетов гораздо безопаснее традиционных сетов БЕЗ ограничений по просадке ....

Сделал тест в ТДС-2 с 2015.01.15 по 2018.05.15 сета [Setka1.43][EURUSD M1][2016.01.04-2018.05.04][DD400 ][K5.53][Grid4,Mult1.2,TP65,Corr2][SetTypeDD-A1]

Торговля сетками без стопов, на мой взгляд, рискованейшее занятие. Торговлю со стопами необходимо исследовать. Почему тест начал с 15-го года? Хотел посмотреть, как все выглядеть может вне границ опта. Мне думается, что надо быть готовым к годам торговли не только около нуля (стагнации) но и уходить в затяжную и достаточно большую просадку. На основании одиночного теста одного сета, пары - делать выводы пока рано. Возможно удастся реализовать анализ мультиторгов несколькими парами сетами с помошью бота для анализа мультиторгов.

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

В приложении отчет теста.

С уважением,

Setka1.43EURUSD_M12016.01.04-2018.05.04DD400_K5.53Grid4Mult1.2TP65Corr2SetTypeDD-A1.gif
Set_OPT__DENYA.rar

Изменено 22 мая, 2018 пользователем chinch19

[Старик]

chinch19, коллега, понимаете, тестирование это процедура, а не свободный полет...

Если (что абсолютно правильно и замечательно!) вы беретесь сделать ретест кем-то выложенного сета, то для начала необходимо предельно точно повторить временной диапазон и другие условия авторского теста, включая отсутствие искусственных проскальзываний.
Это классика - именно так двигается вперед наука.
Независимое повторение тестов/экспериментов 1:1 является обязательным, необходимо получить независимое подтверждение.

И если в результате возникают разночтения, то должна быть возможность тесты сравнить и попытаться понять почему.
Потому что, формально говоря, радикально разных результатов при тестах с фиксированным (!!) лотом на одинаковых или очень близких качественных котировках на 2-х разных компьютерах быть не должно.
И если они всё же возникли, то это не вполне нормально. И надо пытаться понять почему.
Именно поэтому нам и нужны тесты с плавающим спрэдом без использования всяких проскальзываний и искажений спрэда, на тех же или максимально близких котирах и с одинаковым GMT.

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

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

P.S. В сетах/тестах Дэна надо присматриваться к размеру спрэда.
В густых сетках даже малейшая разница в спрэде может крайне влиять на результаты тестирования - и торгов.

[DENYA]

P.S. В сетах/тестах Дэна надо присматриваться к размеру спрэда.
В густых сетках даже малейшая разница в спрэде может крайне влиять на результаты тестирования - и торгов.

Да, коллеги, простите если не написал.... Спред я СОЗНАТЕЛЬНО ставлю под условия EXNESS ECN. Поиск сета с принудительным стопом позволяет стартовать с малого депо, а это открывает некие возможности перейти на условия торговли НЕцентовых брокеров. Как я и писал ранее, с выложенными скринами, если сравнивать торговые условия разных брокеров, то есть сумасшедше выгодные брокеры по затратам на торговые издержки. Скажем EXNESS ECN выгодней по затратам на 30-35% по сравнению с TickMill. TikMill же в свою очередь гораздо выгодней FortFS, который гораздо выгодней Exness Cent.

И тогда у меня и родилась идея перехода на торговлю в ECN-овских счетах. Спреды я брал именно под конкретного брокера EXNESS ECN. Для центовых счетов спреды при прогонах должны быть больше, с неизбежным "изменением" результатов бэктеста.

Кроме того, ПЛАВАЮЩИЙ спред очень сильно повлияет на результаты бэктеста. При маленьком шаге между ордерами при плавающем спреде сетки могут ой как растянуться по сравнению с прогоном с фиксированным спредом.
По проскальзыванию полностью согласен со Стариком. Оно даст непредсказуемые результаты прогона одного и того же сета. Его лучше исключать. Я лично обычно проскальзывание ЗАКЛАДЫВАЮ в стоимость спреда по формуле 10% от среднего спреда.

[Gureyev]

Привет! Это снова я со своими "гениальными" идеями. :d В общем уже сколько времени бьюсь над сетом и вроде получилось что то более менее вменяемое. Но бот естественно льет на определенных участках. Как этот например:

Спойлер

Обойти их стандартными настройками не получается. То есть можно конечно увеличить шаг и величить параметр mintimestep, но как говориться одно лечим другое калечим. Из чего можно сделать вывод что боту не хватает гибкости настроек. Мне кажется было бы здорово добавить в настройки запрет на открывание не только первого, но и второго и далее ордеров (если предыдущая свеча закрылась бычьей селл ордер не открывается). Ну и параметр mintimestep что бы открывался и увеличивался с определенного колена. Такие настройки дали бы куда больше возможностей. И вопрос, параметры CloseAllOrders_ByProfitPercent и CloseAllOrders_ByProfitMoney работают только на реале ? Потому что в тестере никак работь не хочет у меня...

[0ll]

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

Палка всегда с двумя концами... Гибкость настроек ведёт к неопределённому шагу сеток, а это в свою очередь к невозможности посчитать риски, модель торгов (основу данного проекта) - в мусор?
Надо выбирать: или синица в руках или погоня за журавлём, но это, имхо, будет другой проект.

[Gureyev]

а это в свою очередь к невозможности посчитать риски

Видел я как вы просчитываете эти риски, что посливались все на фунте( То что вы пытаетесь просчитать, просчитать не возможно, имхо. Честно не знаю насколько это затратно по времени, но если бы были добавлены такие параметры, такие как я (думаю я не один такой:) с помощью научного тыка может чего и натыкали интересного. Результаты естественно сюда, а там уже видно будет стоит ли гонятся за этим журавлем или нет.

[Nioin]

Такой сет способен с 400$ первоначального баланса и удачного СТАРТА (чтобы сразу не попасть на стоп по просадке)

Приветствую! Чтобы увеличить наши шансы удачного СТАРТА предлагаю оптить полученный сет в советнике с индикаторным входом первых ордеров - [EA] - Setka v1.43 RSI-CCI.

Предлагаю сразу ставить индюки на D1 в настройках и добавить еще третий -- Bollinger Bands.

[Andralex]

Уважаемые коллеги, подскажите пожалуйста. Торгую на Альпари. На сколько по качеству торговля у данного брокера будет отличаться на центовике при четырехзначных котировках от пятизначных от других контор? Имеет смысл торговать на Альпари? Или открыть счет у другого брокера?
P.S. Про ограничение в Альпари в 25 ордеров знаю... Хочу использовать одну пару.

[Sergey-009]

Спойлер

Уважаемые коллеги, подскажите пожалуйста. Торгую на Альпари. На сколько по качеству торговля у данного брокера будет отличаться на центовике при четырехзначных котировках от пятизначных от других контор? Имеет смысл торговать на Альпари? Или открыть счет у другого брокера?
P.S. Про ограничение в Альпари в 25 ордеров знаю... Хочу использовать одну пару.

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

Спойлер

другими словами он входит в рынок позднее, и начинает строить сетку позднее.
помимо ограничения в ордерах и коряво прорисованных свечах, там фиксированный спред если не ошибаюсь 4. Бывает такое что из за этого сетка ордеров не закрывается по тейк профиту, цене надо гораздо дальше пройти что бы она закрылась. Как по мне лучше щета с плавающим спредом.
Недостатки:
ограничения количества ордеров (но для вас это не помеха)
позже входить в рынок из за корявой прорисовки свичей
и из за большего спреда может не закрытся сетка и цена розвернется в другую сторону

[Andralex]

Сегодня сравнивал условия торговли на центовиках у разных ДЦ. Для себя выделил RoboForeх- Pro-Cent. Вроде адекватные условия.

[nonamezzzz]

Здравствуйте Уважаемые.
Начиная с 8 ого колена, бот начал неправильно увеличивать лоты, будьте добры, посмотрите, что я не так сделал
Логи, сет, скрин прилагаю.
Заранее благодарен

Спойлер

logs.rar
EA_-_Setka_v1.43_-_eurjpy_m1_nonamezzzz_-_20180520_-_10к.set