Не пробовали реализовать ММ в виде оптимального F? :-b Здесь на форуме есть страничка.
Например разделить депозит в соотношении 80/20. 80-копилка, 20-супер риск (та часть депо, где совершаются сделки). Как только сделка оказалось профитной - этот профит делится также в соотношении 80/20. 80% плюсуем в копилку, 20% плюсуем в депо, где совершаются сделки и т.д.
[open source] [Советник] Mix Scalper: сконструируй свой Грааль!
От Archmagister, 16 сентября, 2013 в Лаборатория ProfitFX
Такой тип ММ применим только к режиму одной сделки, а данный режим пока не популярен, на него практически отсутствуют сеты. Так что думать о таком слишком рано, но в недалеком будущем, я планирую добавить несколько подобных режимов. В том числе самый на первый взгляд стандартный но тоже отсутствующий режим %% риска на депозит.
И кстати вы немного не правильно привели пример. Но тут уже есть попытка реализовать схожий алгоритм. Отличие только в том что вся прибыль переводится в копилку и если копилка достигла определенного размера то покупаем новую побольше увеличиваем рисковую долю. Толковых отчетов по его работе я так и не получил. Хотя перед выпуском все прекрасно работало.
Кстати DENYA, я по картинкам вообще ничего толкового сказать не могу, мне нужны сеты как минимум, ra0azp скорее всего прав, Этот флажок мог повлиять, Камикадзе режим отключается полностью, раз и на всегда, его блоки всегда имеют проверку включения.
Кстати я кажется не прокомментировал вопрос про Комерцизацию советника. НУ так вот НЕДОЖДЕТЕСЬ. Хотя я бы был бы благодарен получить предложение о постоянной партнерке на памме в размере 3-5 + % v:), я не редко пишу ботов под залог будущей прибыли, ведь на момент написания никто незнает получится ли из него грааль или сливное г. Это самый безрисковый способ благодарности за проделанную работу построенный на взаимном доверии и уважении.
Относительно бота я теоретически подумывал ограничить только распространение самой последней версии (НУ этой, самообучаемой самодумающей"" v:) не для коммерции а для себя ) но и то не факт.
Изменено 18 октября, 2014 пользователем Ttomas
Кстати я кажется не прокомментировал вопрос про Комерцизацию советника. НУ так вот НЕДОЖДЕТЕСЬ. Хотя я бы был бы благодарен получить предложение о постоянной партнерке на памме в размере 3-5 + % v:), я не редко пишу ботов под залог будущей прибыли, ведь на момент написания никто незнает получится ли из него грааль или сливное г. Это самый безрисковый способ благодарности за проделанную работу построенный на взаимном доверии и уважении.
Относительно бота я теоретически подумывал ограничить только распространение самой последней версии (НУ этой, самообучаемой самодумающей"" v:) не для коммерции а для себя ) но и то не факт.
Молодчина! +100500! \M/
Ладно это было маленькое лирическое отступления.
А я продолжу насюсюкивать участников на поиск сетов работы с одиночными ордерами.
Вот пример того что вас ждет уже наверное завтра. Не совсем конечно удачный так как сделок маловато но мне нужно было набросать сетик для проверки работоспособности блока сопровождения. Сам сет внизу и его можно проверить на версии 03.42.
Вот как он выглядит у меня в версии 03.43 _http://gyazo.com/26f9b834e8eadb1b150765567147a441 голым.
А вот так с сопровождением _http://gyazo.com/56c15140884b94a9cf9038cafb98aefa.
Какая статистика больше по душе вопрос риторический.
MxS_03.43_EU_M30_Ttomas_2010-2014_Gen1+Gen2_+_Stoh1_+_Stoh2.set
...Как решить проблему пока незнаю, на досуге попробую просто ограничить индюку просчет баров назад. Чаще всего это помогает.
Да и вообще для советника лучше это сделать в большинстве индикаторов так как ему невыжно сколько и какие сигналы давали эти индикаторы.
Кстати, да, ограничить глубину расчетов индикаторов при вызове стоит по любому.
Это, видимо, и одна из обязательных мер в попытке вернуть боту способность проходить оптимизацию.
Наверно, и на быстродействии это положительно скажется.
Только я бы добавил, что, даже если какие-то индикаторы в бот встроены, в сборку каждой новой версии бота надо добавить автономные версии этих индикаторов с задаваемой глубиной расчетов в барах.
В этом случае форумчане могли бы помочь с определением минимально необходимой достаточной глубины анализа индикаторов в барах, тестируя индикаторы в визуальном режиме.
А то ведь сходу и не скажешь какова минимально необходимая глубина в барах анализа каждого из индикаторов для корректной работы индикатора в боте, правильно?
Ограничивать каждый индикатор вроде надо, но каждый индикатор ограничить насколько?!
Справедливое замечание, но в пунктах оставлю и в % от ТП
тоже согласен.
Но при задании уровней частичного закрытия в пипсах и %% одновременно я бы выполнял частичное закрытие ордера только при достижении ценой более дальнего (от ордера) соответственно 1-го или 2-го уровня частичного закрытия ордера.
Т.е., например, если курс движется к 1-му уровню частичного закрытия, расчетно в %% от ТП это 8 пипсов, а константа 1-го уровня в пипсах пользователем задана =10, то я бы закрывал 1-ю часть ордера при прохождении ценой 10 пипс в сторону ТП, игнорируя достижение 1-го уровня закрытия в % от ТП расчетно =8пп.
На мой взгляд, человек не от балды будет выставлять уровень в пипсах, это должен быть итог расчета с учетом волатильности конкретной пары и спрэдов конкретного ДЦ.
Вообще, имхо, однотипные настройки такого типа, задаваемые людьми, должны иметь приоритет над вычисляемыми - просто потому, что в ручных ТС пользователь обычно долго думает и анализирует где именно частично закрывать ордера на каждой паре.
Ну, и так или иначе придется отработать в коде все возможные комбинации уровней частичного закрытия ордеров в пипсах и %% от ТП.
Я вроде раньше писал, но повторюсь - в программировании паскудненькая эта хрень - закрытие ордеров по частям.
Куда не ткнись - всюду мины.
Во-первых, дребезжание цены - цена может многократно проходить вверх/вниз один или оба уровня частичного закрытия ордера.
Надо надежно хранить флаг отработан или нет каждый уровень частичного закрытия и не производить повторное частичное закрытие ордера на каждом из уровней частичного закрытия ордера в случае дребезжания цены и повторных проходов ценой уровней частичного закрытия ордера.
Да и сам флаг задавать аккуратно надо, а то было, что сигнал на частичное закрытие прошел, попытка частичного закрытия ордера была, но вроде из-за чрезмерного скольжения (или поток занят, не помню?) цена стала хуже уровня закрытия, частичное закрытие отменилось, а в флажке несостоявшееся частичное закрытие зафиксили как состоявшееся. Этот моментик тоже надо выплясать аккуратненько.
Во-вторых, надо надежно хранить начальный размер/объем ордера, т.к. 2-е частичное закрытие ордера (если это не закрытие всего остатка ордера) обычно должно вычисляться и (согласно настроек пользователя) производится от полного начального объема ордера.
В-третьих, еще одна сложность в том, что при частичном закрытии ордера, вместо первичного ордера выставляет новый ордер меньшего объема с другим №, причем коммент в нем вроде затирается служебным текстом и свою инфу о начальном ордере в комменте нового ордера не сохранишь.
Так что, на случай необходимости отключения/перегрузки терминала, похоже, надо инфу об ордере и отработанных уровнях частичного закрытия выносить во внешние переменные, экстернал или глобал. (Проверьте экстернал как рабочую для бота - если ей значение из программы присваивать можно, то, может, несколько таких рабочих ext переменных и придется завести для хранения служебной инфы бота о частичнм закрытии ордеров.)
В-четвертых, частичное закрытие надо тестировать очень тщательно и обычными прогонами в тестере за месяц-два тут не отделаешься.
Надо подбирать короткие участки на истории с частичным закрытием ордеров и на них выполнять локальное тестирование, в т.ч., тестирование в визуальном режиме.
Причем проверить надо все реальные комбинации управляющих параметров и движений цены, а их немало...
Комплексное тестирование пока не самая сильная ваша сторона, а эту опцию надо проверять очень тщательно и планомерно.
В общем, нагрузил. :d
Революционного я ничего не написал, но некоторые нюансы перечислил.
Удачи!
Старик Как в случае с Хилари Вы сделали "Перегрузку" :d
И в первом и во втором вопросе могут быть более простые и эффективные решения, имхо:
1. При ограничении глубины расчётов в барах мы ускоряем процесс начала тестирования (загрузки), само время тестирования зависит только от алгоритмов вычисления. Я даже не уверен, что память освободится МТ может грузить всю историю, а работать только на последних Х-барах. Если я не прав - поправьте пожалуйста.
2.
- дребезжание цены конечно есть, но обрабатывать этот момент зачем? фактически цена достигла уровня - вкл. флаг контроля исполнения и исполнили - без доп. проверок. Эта фича (частичн. закрытие позы) не критична и к сливу не приведёт, ну 1 из 10 раз закроет немного не там, проскользит - ну и х...орошо.
- в случае проблем с терминалом: сова пересчитала ордера и "забыв" ещё раз частично закрыла - ну и опять хорошо! это архи-редкое событие легко пережить.
- а вот про тестирование согласен. :)
Старик бот и так очень сложный и нагромождать не очевидными проверками имхо не стоит.
И в первом и во втором вопросе могут быть более простые и эффективные решения, имхо:
1. При ограничении глубины расчётов в барах мы ускоряем процесс начала тестирования (загрузки), само время тестирования зависит только от алгоритмов вычисления. Я даже не уверен, что память освободится МТ может грузить всю историю, а работать только на последних Х-барах. Если я не прав - поправьте пожалуйста.
2.
сильно спорно. Код расчёта уровней част. закрытия в разных вариантах конечно нужен, но пользователь должен выбрать 1 вариант и его использовать.Цитата... в ручных ТС пользователь обычно долго думает и анализирует где именно частично закрывать ордера на каждой паре
- дребезжание цены конечно есть, но обрабатывать этот момент зачем? фактически цена достигла уровня - вкл. флаг контроля исполнения и исполнили - без доп. проверок. Эта фича (частичн. закрытие позы) не критична и к сливу не приведёт, ну 1 из 10 раз закроет немного не там, проскользит - ну и х...орошо.
- в случае проблем с терминалом: сова пересчитала ордера и "забыв" ещё раз частично закрыла - ну и опять хорошо! это архи-редкое событие легко пережить.
- а вот про тестирование согласен. :)
Старик бот и так очень сложный и нагромождать не очевидными проверками имхо не стоит.
Изменено 19 октября, 2014 пользователем 0ll
1 Ограничить я глубину расчета индикаторов нужно в любом случае. Оптимизация наверное по тому и вешается что при прогоне N раз ему придется проводить N раз запуск и это же количество раз пересчитывать индикаторы... Я бы тоже повесился. МТ в любом случае загрузит всю историю, только вот проводить математические операции по расчету индюка не будет а соответственно ресурс не будет потрачен.
На самом деле я не хочу нагружать модуль дублированной проверкой Фиксированных уровней и Динамических. Пару месяцев назад мы обсуждали кажется что нужно делать так чтобы робот был адаптивным для волантильности. А кто будет подстраивать размер фиксированных уровней под эту волантильность, если вдруг не получится у пользователя подойти к терминалу пару месяцев. Чтобы уровни не были слишком короткими при Динамическом ТП и СЛ есть у нас фильтр по минимальной ширине канала.
Функцию сопровождения я уже сделал, я сразу предусмотрел в ней многократное касание уровня, тут несколько вариантов. Все выполнилось - ничего не предпринемается так как все как часики. Если лот минимален и закрывать часть не целесообразно происходит простое перенесение СЛ. Если Ордер был закрыт то модификация не требуется. Если закрыть лот не удалось то просто пытаемся перенести уровень в БУ (не зафиксировали так хотябы защитим) .Если ордер существует то модифицируем. Если даже модификация не удалась то мы зафиксировали часть ордера и это тоже неплохо. И при следующем тике(попытке) попробуем все сначала. НА каждую операцию имеется некоторое количество попыток. Теоретически возможны ошибки исполнения, но я постарался все исходы этих ошибок свести к положительным сторонам - сохранению средств в ущерб некоторой упущенной прибыли. Ведь если на рынке так не спокойно что тики ка бешеные туда сюда летают то стоит вообще закрыть и курить на заборе
Во-вторых, надо надежно хранить начальный размер/объем ордера, т.к. 2-е частичное закрытие ордера (если это не закрытие всего остатка ордера) обычно должно вычисляться и (согласно настроек пользователя) производится от полного начального объема ордера.
Уже предусмотрено. Расчет второй части закрытия ведется с восстановлением исходного лота ордера. Хранить переменные не стал.
Третье Предусмотренно, после закрытия ордера проводится поиск среди всех ордеров, ордера с такими же ТП Ценой открытия и Финальным Лотом, тикет которого и возвращается обратно в функцию сопровождения, где происходит перевыбор и цикл модификации.
По тестированию согласен, не самая моя сильная сторона, хотя я в визуале пронаблюдал эти 100 сделок отдельно каждую.
0ll, я высказал даже не имху, сколько дал как-то сгруппированную инфу.
И это ж не приказ, обязательный к исполнению, а информация к размышлению.
Возможно, для одиночных ордеров какие-то из моих предложений могут показаться чрезмерными, какие-то слишком сложными, какие-то не оптимальными.
Даже не спорю.
Но если речь идет о более чем одном ордере в "плюсовой" доливочной, а не мартин сетке, то неоптимальность или неполнота реализации частичного закрытия ордеров проявится сильнее, а может и вообще не позволит корректно отрабатывать частичное закрытие более чем одного ордера.
Так что на нижнем уровне (отработке 1-го ордера) вроде стоит продвигаться как можно дальше.
Можно взглянуть и по другому: какие-то риски вы, может, недооцениваете - а цену (потери) каких-то занижаете.
Скажем, дребезжание цены - она ж конкретно дребезжит, сабака!... :)
И не 1 раз из 10 цена пару раз "пройдется" по уровню частичного закрытия ордера, а 2-3, а может и 5 раз.
Допустим, на 50% ТП установлен 1 уровень 50% закрытия ордера.
Тогда, при дребезжании цены и двухкратном закрытии части (50%) ордера на 1-м уровне частичного закрытия мы потеряем 33% его прибыли.
Если же по дребезгу цены на 1-м уровне частичного закрытия ордера закроется 3 ордера из 10, то мы потеряем 10% всей прибыли от торгов, верно же?
Конечно, при разных настройках цифры будут меняться, но отсутствие блокировки повторного частичного закрытия ордера на одном уровне - это далеко не бесплатно.
И естественен вопрос что правильней: подумать лишние 2-3 дня и сделать оптимально - или недобирать до 10%-15% прибыли всегда и везде потом на неполной реализации?
По себе знаю, что программистов иногда настигает ощущение всемогущества и совершенства сделанного.
Ну помощник наместника Бога, как минимум.
Помню, меня какое-то время плющило после безупречного полета Бурана на полном автомате - было ощущение совершенства сделанного.
Хотя в проекте отработало 200000+ человек в течение многих лет и мой вклад был пропорциональный участию, не более.
Но в том проекте программирование было бескомпромиссным: было запрограммировано абсолютно все - и все запрограммированное было протестировано как в автономе в сложнейших тестовых моделях, так и на специальных стендах совместно с оборудованием птицы и разгонного блока.
Совершенство сложное и трудное, но оно прекрасно.
Оно достижимо: единицам и далеко не всегда - но достижимо.
История микс скалпера несколько нелинейна: проверка определенных идей, в т.ч. идеи пользовательского конструктора, но без реализации серьезного сопровождения торгов - а сейчас взялись за последнее и там просто тьма работы.
На мой взгляд, достойная реализация сопровождения ордеров, вообще основных опций управления торгами требует создания за год-два достойного полнофункционального бота-носителя.
И вот только на таком боте-носителе и можно проверять потом разные ТС и выжимать из прибыльных ТС максимум прибыли.
Пока же под 100% программистов мира лепят горбатого: по минимуму реализуют ТС с отсутствующим или минимальным кривым сопровождением торгов - и отправляют в мусорку сотни ботов только потому, что надлежащего сопровождения ордеров/торгов в них нет.
Микс скалпер чудесен тем, что, может быть, бот будет доведен до достойного уровня по итогам долгого и тяжкого труда - но многое еще впереди.
Это я к тому, что ссылка на "уже сложный бот" несостоятельна: хотите состязаться с Богом - попробуйте быть таким же безупречным, как и Он.
Надо ли пробовать стремиться к совершенству?
Ну, мужчине, которому Бог дал, один раз в жизни стоит посвятить несколько лет попытке. :)
Но можно и съехать с темы, мол и так сложно - Бог-то простит.
:) Ладно, понятно о чем я.
Сколько-то инфы я выложил, а насколько углубляться и упираться - это по ситуации.
А, вот и Ttomas отписался - нормально роет, глубины не боится!... :d
И это ж не приказ, обязательный к исполнению, а информация к размышлению.
Возможно, для одиночных ордеров какие-то из моих предложений могут показаться чрезмерными, какие-то слишком сложными, какие-то не оптимальными.
Даже не спорю.
Но если речь идет о более чем одном ордере в "плюсовой" доливочной, а не мартин сетке, то неоптимальность или неполнота реализации частичного закрытия ордеров проявится сильнее, а может и вообще не позволит корректно отрабатывать частичное закрытие более чем одного ордера.
Так что на нижнем уровне (отработке 1-го ордера) вроде стоит продвигаться как можно дальше.
Можно взглянуть и по другому: какие-то риски вы, может, недооцениваете - а цену (потери) каких-то занижаете.
Скажем, дребезжание цены - она ж конкретно дребезжит, сабака!... :)
И не 1 раз из 10 цена пару раз "пройдется" по уровню частичного закрытия ордера, а 2-3, а может и 5 раз.
Допустим, на 50% ТП установлен 1 уровень 50% закрытия ордера.
Тогда, при дребезжании цены и двухкратном закрытии части (50%) ордера на 1-м уровне частичного закрытия мы потеряем 33% его прибыли.
Если же по дребезгу цены на 1-м уровне частичного закрытия ордера закроется 3 ордера из 10, то мы потеряем 10% всей прибыли от торгов, верно же?
Конечно, при разных настройках цифры будут меняться, но отсутствие блокировки повторного частичного закрытия ордера на одном уровне - это далеко не бесплатно.
И естественен вопрос что правильней: подумать лишние 2-3 дня и сделать оптимально - или недобирать до 10%-15% прибыли всегда и везде потом на неполной реализации?
По себе знаю, что программистов иногда настигает ощущение всемогущества и совершенства сделанного.
Ну помощник наместника Бога, как минимум.
Помню, меня какое-то время плющило после безупречного полета Бурана на полном автомате - было ощущение совершенства сделанного.
Хотя в проекте отработало 200000+ человек в течение многих лет и мой вклад был пропорциональный участию, не более.
Но в том проекте программирование было бескомпромиссным: было запрограммировано абсолютно все - и все запрограммированное было протестировано как в автономе в сложнейших тестовых моделях, так и на специальных стендах совместно с оборудованием птицы и разгонного блока.
Совершенство сложное и трудное, но оно прекрасно.
Оно достижимо: единицам и далеко не всегда - но достижимо.
История микс скалпера несколько нелинейна: проверка определенных идей, в т.ч. идеи пользовательского конструктора, но без реализации серьезного сопровождения торгов - а сейчас взялись за последнее и там просто тьма работы.
На мой взгляд, достойная реализация сопровождения ордеров, вообще основных опций управления торгами требует создания за год-два достойного полнофункционального бота-носителя.
И вот только на таком боте-носителе и можно проверять потом разные ТС и выжимать из прибыльных ТС максимум прибыли.
Пока же под 100% программистов мира лепят горбатого: по минимуму реализуют ТС с отсутствующим или минимальным кривым сопровождением торгов - и отправляют в мусорку сотни ботов только потому, что надлежащего сопровождения ордеров/торгов в них нет.
Микс скалпер чудесен тем, что, может быть, бот будет доведен до достойного уровня по итогам долгого и тяжкого труда - но многое еще впереди.
Это я к тому, что ссылка на "уже сложный бот" несостоятельна: хотите состязаться с Богом - попробуйте быть таким же безупречным, как и Он.
Надо ли пробовать стремиться к совершенству?
Ну, мужчине, которому Бог дал, один раз в жизни стоит посвятить несколько лет попытке. :)
Но можно и съехать с темы, мол и так сложно - Бог-то простит.
:) Ладно, понятно о чем я.
Сколько-то инфы я выложил, а насколько углубляться и упираться - это по ситуации.
А, вот и Ttomas отписался - нормально роет, глубины не боится!... :d
Изменено 19 октября, 2014 пользователем Старик
Старик По поводу дребезга цены на уровне - только сейчас понял Вашу мысль. естественно согласен, что нужно избежать многократных срабатываний.
От Бурана меня тоже плющило - я только начал программировать. Кстати моим учителем был 1/200000...
Про Бога, мужчин и совершенство - без комментариев... я стараюсь давить в себе перфекциониста...
От Бурана меня тоже плющило - я только начал программировать. Кстати моим учителем был 1/200000...
Про Бога, мужчин и совершенство - без комментариев... я стараюсь давить в себе перфекциониста...
0ll, перфекционизм зло и часто причина утраты невосполнимого времени без результата.
Но фора враждебная, почти как космос, среда, почти не совместимая с жизнью.
Именно поэтому, чтобы выжить, программировать на форе надо или по взрослому, или никак.
Я примерно об этом писал как смог. :)
Но фора враждебная, почти как космос, среда, почти не совместимая с жизнью.
Именно поэтому, чтобы выжить, программировать на форе надо или по взрослому, или никак.
Я примерно об этом писал как смог. :)
Кстааати... я вот тут битый час прокручиваю алгоритм сопровождения чтоб предусмотреть все что можно и что нельзя и пришел к одному умозаключению. Так как весь алгоритм заточен на сопровождение одного ордера да и еще на тф 15+ то соответственно цели у него будут не маленькие. Соответственно Если алгоритм активировался то цена по любому коснулась или была выше\ниже уровня ( так как для определения касания используется Бид для Баев и Аск для селов). Далее идет активация алгоритма закрытия цикл N попыток с рефрешем в начале и маленькой паузой в конце или дополнительной паузой в случае если торговый канал занят. Но допустим что не помогло и ордер не закрылся ( полностью или частично) тогда продолжается алгоритм модификации который не привязан к цене Бид или аск а напрямую модифицирует СЛ ордера расчитанным ранее уровнем ( уровнем открытия для 1 лвла и уровнем первого лвла для 2 лвла) соответственно те же N попыток рефреша с паузой и обработкой ошибки. И если только цена гепом не преодолеет расстояние между уровнем активации и предположительным СЛ то модификацию ничто не остановит. Ведь когда мы говорим о Модуле сопровождения ордера для режима одной сделки то говорить о целях в 5 пунктов врятле приходится, а подобный геп в 1 тик для М15 и выше размером в 10-20+ пунктов врятле возможен. Если модификация СЛ ордера произойдет то повторное перезакрытие для этого ордера возможно только в случае ручного вмешательства и принудительного увеличения тп . И то я сейчас введу пару дополнительных фильтров Например если СЛ больше Цены открытия то первый уровень не перезакрывать. ТАк как он теоретически уже был отработан. С отработкой второго уровня ничего наверное не попишешь. ТАк что пока бот будет работать в автоматическом режиме и пользователь не будет вмешиваться в его ТП с целью увеличить на порядок то думаю никаких проблем не будет. Хотя такое понятие как максимальное отклонение цены вызова функции от цены исполнения добавить стоит.
Добавлено: 20-10-2014 10:20:49
Я вроде придумал все что только можно, и никаких дополнительных озарений не пришло. Поэтому выкладываю на рассмотрение свежую версию под порядковым номером 03.43 :d
что было сделано в данной версии:
1 - Самое главное: Модуль сопровождения одиночных ордеров. При достижении ценой первого уровня закрывается часть ордера а сл переносится на уровень открытия + SoloMoveDopPoint (для поправки на спред) Как только модификация СЛ произошла повторное закрытие на этом уровне не произойдет несмотря на дребезг цены. Как только цена пешагнула второй уровень закрывается еще одна часть ордера и СЛ переносится на первый уровень + SoloMoveDopPoint. После перемещения СЛ повторное перезакрытие не произойдет. изменять ТП работающего ордера с отработанным 2м уровнем не рекомендую так как если сделать его меньше он забъет на вас а если больше то он попытается еще раз закрыть часть ордера по второму уровню без учета уже имеющегося закрытия на 2м уровне. Так же не рекомендую использовать совместно с модулем БУ так как он перенесет сл раньше и модуль соопровождения посчитает что первый уровень уже отрабатывался.. в комплекте есть еще один хитрый параметр MaxCloseDopForSoloMove - это максимальное ухудшение цены для закрытия части позиции в пунктах, если ухудшится слишком сильно то плевать на закрытие, будем просто переносить в БУ. Для определения типа исчисления уровней используется параметр SoloMovingType если 0 то исчисление в пунктах если 1 то в процентах. остальные параметры вроде говорящие и вопросов возникнуть не должно. Ну и естественно не надо делать первый уровень больше второго и всякие другие штуки которые противоречат логики, Бот разрабатывался на адекватных и понимающих пользователей. Параметры вынес пока в самое начало, после тестирования и устранения возможных непредвиденных ошибок перемещу в раздел сопровождения.
2 - Добавил ограничения во все внешние индикаторы, проверил их работу... вроде нормально и даже ссрц показывает внятно если будут найдены косяки с ними пишите.
3 По функции ММ прошелся там все на своих местах и не перепутано, никаких ошибок нет.
Вроде бы все.
Ну вот еще один случайный сетик с мартином
Mix_Skalper_v03.43.rar
MxS_03.43_EU_M30_Ttomas_2010-2014_Odzi1+_Stoh1.set
Изменено 20 октября, 2014 пользователем Ttomas
подозреваю, что совмещение частичного закрытия с двигающимся несколько уровневым б/у может привести к частому преждевременному выбиванию ордеров по б/у.
Надо тестировать, но я бы опции все же разделял и включение/движение б/у выполнял бы если не позже, то дальше (ближе к ордеру).
именно из за риска частого выбивания по б/у из-за дребезжания цены.
А так весьма интересная реализация сопровождения в этой части, компактная как бы.
Старик как всегда зрите в Корень!
Вообще я именно вот этот блок сопровождения писал вдохновленный вот этим постом. Когда меня все вроде бы стало устраивать и соответствие было достигнуто приблизительно полно я его выложил. + дополнил вновь подчерпнутой информацией. Хотя за время написания и многократного прокручивания алгоритма появилось несколько идей которые стоит реализовывать похоже но чуть отдельно.
Я хочу сделать маленький конструктор внутри конструктора. Конструировать будем именно блок сопровождения. Обрабатывать он будет все ордера в том же направлении читай доливочные тоже. Предполагается что будет доступно несколько вариантов действий с каждым из уровней. Например я все-таки разделю Фиксированный уровень и динамический ( условие выбора будет если динамический меньше фиксированного то опираемся на фиксированный но его не стоит слишком завышать ) так же предполагаю что действие с уровнем будут различные - например Закрывать\незакрывать часть ордера. по модификации будут доступны - не трогать СЛ, сдвинуть СЛ на размер уровня реакции, перевести в БУ. перевести на один из основных уровней, включить трал.
При этом динамические уровни предположительно будут обрабатываться как наименьший открытый ордер НАидальний ТП (По сценарию набора позиции). БУ будет высчитыватся по всем открытым ордерам в том же направлении. Будет несколько уровней реакции не 2 а скажем 3 или даже 4. все будет организовано Как нибудь цивильно, в идеале может будет пересохраняться в файл так как работать предполагается с массивом ордеров. В общем простор действий будет огромным, я буду потихоньку продолжать ТЗ которое пишу уже некоторое время, но от дополнительных примеров сопровождения не откажусь, за последние 2-3 дня много чего интересного подчерпнул а последние диалоги так вообще кладесь которую я обязательно"Поставлю в рамочку" сохраню в библиотеке. :)
Вообще я именно вот этот блок сопровождения писал вдохновленный вот этим постом. Когда меня все вроде бы стало устраивать и соответствие было достигнуто приблизительно полно я его выложил. + дополнил вновь подчерпнутой информацией. Хотя за время написания и многократного прокручивания алгоритма появилось несколько идей которые стоит реализовывать похоже но чуть отдельно.
Я хочу сделать маленький конструктор внутри конструктора. Конструировать будем именно блок сопровождения. Обрабатывать он будет все ордера в том же направлении читай доливочные тоже. Предполагается что будет доступно несколько вариантов действий с каждым из уровней. Например я все-таки разделю Фиксированный уровень и динамический ( условие выбора будет если динамический меньше фиксированного то опираемся на фиксированный но его не стоит слишком завышать ) так же предполагаю что действие с уровнем будут различные - например Закрывать\незакрывать часть ордера. по модификации будут доступны - не трогать СЛ, сдвинуть СЛ на размер уровня реакции, перевести в БУ. перевести на один из основных уровней, включить трал.
При этом динамические уровни предположительно будут обрабатываться как наименьший открытый ордер НАидальний ТП (По сценарию набора позиции). БУ будет высчитыватся по всем открытым ордерам в том же направлении. Будет несколько уровней реакции не 2 а скажем 3 или даже 4. все будет организовано Как нибудь цивильно, в идеале может будет пересохраняться в файл так как работать предполагается с массивом ордеров. В общем простор действий будет огромным, я буду потихоньку продолжать ТЗ которое пишу уже некоторое время, но от дополнительных примеров сопровождения не откажусь, за последние 2-3 дня много чего интересного подчерпнул а последние диалоги так вообще кладесь которую я обязательно
Изменено 20 октября, 2014 пользователем Ttomas
Ttomas, понял - вы прониклись темой и видите её очень хорошо.
Перечень рассматриваемых опций воодушевляет.
Я даже сказал бы, что, пожалуй, стоит продумать приоритетность опций и аккуратненько, без суеты начать реализацию с вероятно наиболее востребованных.
Работы просматривается так много, что аж несколько не по себе...
Удачи!
Перечень рассматриваемых опций воодушевляет.
Я даже сказал бы, что, пожалуй, стоит продумать приоритетность опций и аккуратненько, без суеты начать реализацию с вероятно наиболее востребованных.
Работы просматривается так много, что аж несколько не по себе...
Удачи!
Да.... Работы много... Ничего главное я вижу что да как должно выглядеть в коде, а там как всегда Аппетит приходит во время еды. Для начала единый подход и хранение сформирую. Дальше разработаю авто расчет уровней а затем уже потихоньку накручу отработку уровней по варианту... это так, приблизительный план действий.
НА старших тф я хочу сконцентрировать людей потому что там проще получить стабильные системы. Скальпинг это тонкое дело. И очень зависимое от любого чиха, не то что Часовые ТФ.
Напомню: Предложенный ранее локер+усреднитель работал в точности с заявленным ТЗ. как пить дать. ТАк что если хочешь чтоб я в его сторону посмотрел еще раз, напиши адекватное ТЗ. И я его поставлю в очередь. Ведь после его ввода небыло никаких отчетов о том что он работает не так как заказано, он работал как заказано и тупил на ровном месте, хотя предложений по исправлению я так и не получил. :)
Добавлено: 20-10-2014 20:07:29
Нужна помощь с построением логики.
В общем я определил для модуля вот такое направление развития - все ордера в одном направлении являются доливочными (допускаю что если ордер чуть ниже самого первого то он был для набора позиции но не суть) в общем уровни считаются от самого нижнего бай или самого верхнего селл. До самого дальнего ТП (в режиме доливки это будет первый расчитанный) в динамическом режиме работы. Так вот. Как поступить с остальными ордерами? Скорее всего выровнять их СЛ и ТП а дальше перемещать
Хочу услышать мнения, особенно Старик'а как особо сведующего в вопросах как должно выглядить толковое сопровождение.
Понимаю что пытаться написать такой модуль быстро бесполезно, но вдохновение есть вдохновение... Каждый модуль нужно делать на одном дыхании, сейчас занимаюсь каркасом..
Если кому полезно будет то вот приблизительный каркас будущего модуля _http://gyazo.com/2214ef43c66b2911a0da8cf49e82cdfe одна стрелочка это путь внутри управляющего модуля две - вызов внешней функции, хотя тут обозначено много вызовов но для экономии я запоминаю результаты и пересылаю их по мере надобности из главной функции, ну кроме как в функциях где они нужны только 1 раз.
Изменено 21 октября, 2014 пользователем Ttomas
Ну ребят проверил TMA+CG в своём боте, тест провёл на Н1, а значения таймфрейма были по Н4. Вывел данные через "коммент" на экран, оказалось данные при вызове из бота действительно поступают, билд (735).
Не понятно только к чему так извращаться, почему не сделать отрисовку индикатора при тесте в визуальном режиме, чтобы иметь возможность проверить правильность работы и визуальный анализ для возможной корректировки системы?
Хочу ещё поинтересоваться, кто может точно сказать? Возможно я уже что-то туплю, но не могу сообразить, должны ли совпадать значения индикаторов при следующих параметрах: Н1 с периодом (224) и Н4 с периодом (56)? Когда проверял, накладывал для сравнения Н1 с периодом (224), значения оказывались практически идентичными, но вроде же всё равно канал по Н4 должен быть шире, потому как должны использоваться максимальные точки отклонения за 4 часа.
Тут в тма сг есть свои заморочки. Во первых его границы канала отличаются от границ каналов Тма лайна так как строятся не помню точно но связанно с хаями лоями. Что то типо взвешенная по лоям и взвешенная по хаям. Во вторых при его работе всегда выполняется поиск комбинации баров на текущем тф. Тоесть передачей ему тф 4 часа можно получить соответствующую границу но сигнал сформируется по свечной комбинации с текущего. Поэтому увеличением периода тут не обойтись так как все бары попадут в расчет и усреднение при построении границ.
Ну я так и думал, что даже при расчёте на Н1 с установленным в настройках Н4, всё равно поступают усреднённые данные с Н1. Индикаторы пока ещё не доводилось писать, но вообще возможно как-то сделать корректный расчёт со старшего таймфрейма? Раньше похоже это компенсировалось за счёт "взгляда в будущее" при проведении тестов и получалось что примерно соответствовало, а теперь не знаю, неужели придётся делать считывание с другого графика?
День добрый.
При обновлении МТ4 с 711 билда на 735
произошла потеря данных из сетов:
Спойлер
Полностью удалились все описания, заголовки, комменты.
Логика не пострадала, сделки происходили правильно:
- открытие;
- сопровождение;
- закрытие по ТП и обратному сигналу.
Заметил при утреннем "обходе".
Пришлось срочно перезагружать сеты из архива,
проверять и перегружать МТ4.
После перезагрузки МТ4 с уже обновлённым билдом
этих проблем не возникало.
Проверьте свои сеты.
Р.S.: логов не сохранилось.
А что за ошибка может быть:
2014.10.21 20:34:52.049 zero divide in 'Mix Skalper v03.39.mq4' (1482,40)
билд 735
Товарищи, подскажите как после оптимизации все параметры получившиеся прогнать на форвард тесте? Что то никак не пойму. А то по одному перебирать это нечно ~x(
ИМХО Просьба сильно не пинать.
Гонял с разными настройками и тд, и по моему основная проблема, в том что Бот сильно запаздывает с открытием сделки и, как результат, бесконечные усреднения и мартины.
Робот открывает сделку тогда, когда пора закрывать, мне кажется надо просто сделать другой принцип, как пример тралить отложенки по границам канала (что я делаю вручную) вот типа того (график М1)
[SPOILER]
и тогда сделки будут на пиках (пример на скрине), а ТП на середину канала, или кому как нравится, у меня 50пп.
И больше не надо никаких безумных наворотов.
Вручную работаю по Победе отложенками, все Ок, редко усредняюсь.
Изменено 31 октября, 2014 пользователем sbonch
СпойлерИМХО Просьба сильно не пинать.
Гонял с разными настройками и тд, и по моему основная проблема, в том что Бот сильно запаздывает с открытием сделки и, как результат, бесконечные усреднения и мартины.
Робот открывает сделку тогда, когда пора закрывать, мне кажется надо просто сделать другой принцип, как пример тралить отложенки по границам канала (что я делаю вручную) вот типа того
и тогда сделки будут на пиках (пример на скрине), а ТП на середину канала, или кому как нравится.
И больше не надо никаких безумных наворотов.
В ручную работаю по Победе отложенками, все Ок, редко усредняюсь.
Это - извечная проблема. Она идёт от того, что ... все индикаторы запаздывают. Нет ни одного, который бы наверняка указал, что через пару-другую свечей будет разворот. Поэтому всё основано на предположениях и на показаниях тех индикаторов, по которым написано ТЗ и, собственно, сам советник. >:d
Для публикации сообщений создайте учётную запись или авторизуйтесь
Перейти к списку тем