Два вопроса.
По первому вопросу поддерживаю. Только предлагаю не формулу, а просто одну (глобальную) булевую переменную (можно не булевую) с фиксированным именем на закладке Оптимизация. Эксперт будет записывать ее значение, а оптимизатор проверять. Таким образом будут быстрее отсекаться бесполезные прогоны и главное - не будут заноситься в результаты оптимизации.
Также ускорится время оптимизации, добавится гибкость. Ведь очевидно, что не хватает жестких выходных параметров.
Пожалуйста, не пропускайте это предложение, так как входные параметры можно задавать какие угодно, но с выходными показателями... напряжно.
Ну, а сказкой будет возможность задавать сколько угодно пременных :-)
Господа, поддержите это предложение.
Также ускорится время оптимизации, добавится гибкость. Ведь очевидно, что не хватает жестких выходных параметров.
Пожалуйста, не пропускайте это предложение, так как входные параметры можно задавать какие угодно, но с выходными показателями... напряжно.
Ну, а сказкой будет возможность задавать сколько угодно пременных :-)
Господа, поддержите это предложение.
1. Целевую функцию вводить не будем - это 100%
Есть 5 целевых функций оптимизации. Мы не считаем нужным усложнять систему ради нерабочих случаев. То есть, кастомные целевые функции - это желание трейдеров самостоятельно поиграться, результатом чего будет четкий вывод "это не дает серьезных результатов". Мы этот момент уже обсуждали.
2. Практическое большинство экспертов не смогут работать в двух режимах без переоткрытия на свопах и с переоткрытием. То есть, надо писать специализированных экспертов.
Есть 5 целевых функций оптимизации. Мы не считаем нужным усложнять систему ради нерабочих случаев. То есть, кастомные целевые функции - это желание трейдеров самостоятельно поиграться, результатом чего будет четкий вывод "это не дает серьезных результатов". Мы этот момент уже обсуждали.
2. Практическое большинство экспертов не смогут работать в двух режимах без переоткрытия на свопах и с переоткрытием. То есть, надо писать специализированных экспертов.
2 Renat:
А оптимизация по критерию "прибыль, приведенная к просадке" не обсуждалась? Поясню подробнее: пусть я оптимизирую с постоянным лотом и получаю в одном случае прибыль 7000 с просадкой 2000, а в другом 4000 с просадкой 1000. Очевидно, во втором случае я могу просто увеличить размер лота в два раза и при том же риске, что и в первом варианте, получить прибыль 8000. То есть, информативным для меня в данном случае будет именно показатель прибыль, делённая на просадку. Смысл оптимизации с постоянным лотом по моему разумению в том, что при включении в игру в самый неудачный момент максимальную просадку будет держать именно начальный депозит.
А оптимизация по критерию "прибыль, приведенная к просадке" не обсуждалась? Поясню подробнее: пусть я оптимизирую с постоянным лотом и получаю в одном случае прибыль 7000 с просадкой 2000, а в другом 4000 с просадкой 1000. Очевидно, во втором случае я могу просто увеличить размер лота в два раза и при том же риске, что и в первом варианте, получить прибыль 8000. То есть, информативным для меня в данном случае будет именно показатель прибыль, делённая на просадку. Смысл оптимизации с постоянным лотом по моему разумению в том, что при включении в игру в самый неудачный момент максимальную просадку будет держать именно начальный депозит.
1. Целевую функцию вводить не будем - это 100%
Есть 5 целевых функций оптимизации. Мы не считаем нужным усложнять систему ради нерабочих случаев. То есть, кастомные целевые функции - это желание трейдеров самостоятельно поиграться, результатом чего будет четкий вывод "это не дает серьезных результатов". Мы этот момент уже обсуждали.
2. Практическое большинство экспертов не смогут работать в двух режимах без переоткрытия на свопах и с переоткрытием. То есть, надо писать специализированных экспертов.
Есть 5 целевых функций оптимизации. Мы не считаем нужным усложнять систему ради нерабочих случаев. То есть, кастомные целевые функции - это желание трейдеров самостоятельно поиграться, результатом чего будет четкий вывод "это не дает серьезных результатов". Мы этот момент уже обсуждали.
2. Практическое большинство экспертов не смогут работать в двух режимах без переоткрытия на свопах и с переоткрытием. То есть, надо писать специализированных экспертов.
1. Выходной параметр в виде Профит/Просадка, это не желание поигратся, это я вам гарантирую. Если вы со мной несогласны, то наверно я тут просто теряю время =). Его критически не хватает. Может запись целевой функции в виде формулы не добавлять (черт с ней), но этот обязательно должен быть. (кстати и в отчете тоже должен быть, и в результатах оптимизации тоже, но его почему то там нет)
2. Все из за чего приходится писать доп условия и лезть в глобальные переменные, это из за того что ордер теряет его изначальную цену открытия. Я уже написал что я эту проблему решаю у себя, но способ (с использованием глобальных переменных для запоминания цены открытия), меня катастрофически не устраивает.
1. Выходной параметр в виде Профит/Просадка, это не желание поигратся, это я вам гарантирую. Если вы со мной несогласны, то наверно я тут просто теряю время =). Его критически не хватает. Может запись целевой функции в виде формулы не добавлять (черт с ней), но этот обязательно должен быть. (кстати и в отчете тоже должен быть, и в результатах оптимизации тоже, но его почему то там нет)
О таком параметре оптимизации мы не подумали. Обсудим, протестируем и наверняка добавим как штатный параметр оптимизации торговых стратегий.
Мы не против хороших штатных целевых функций, но против кастомных вариантов.
1. Выходной параметр в виде Профит/Просадка, это не желание поигратся, это я вам гарантирую. Если вы со мной несогласны, то наверно я тут просто теряю время =). Его критически не хватает. Может запись целевой функции в виде формулы не добавлять (черт с ней), но этот обязательно должен быть. (кстати и в отчете тоже должен быть, и в результатах оптимизации тоже, но его почему то там нет)
О таком параметре оптимизации мы не подумали. Обсудим, протестируем и наверняка добавим как штатный параметр оптимизации торговых стратегий.
Мы не против хороших штатных целевых функций, но против кастомных вариантов.
Да вы сразу столкнетесь с неприятностью, что если после результатов прогона у вас будет 10 сделок в профит и 1 в минус (подразумевается размер профита и потерь одинаков), то эксперт будет орать что у него замечательный показатель Профит/Просадка. И он будет считатся лутше чем если бы было 80/30 (что явно неверно). А вот фильтра на "минимальное количество сделок" нет... Кстати он тоже нужен... Но его опять таки обделили вниманием... Вобщем. Еще нужен фильтр на минимальное количество сделок =)
А по каким ещё параметрам можно оптимизировать экспертов?
Только, пожалуйста, аргументированно.
Только, пожалуйста, аргументированно.
А по каким ещё параметрам можно оптимизировать экспертов?
Только, пожалуйста, аргументированно.
Только, пожалуйста, аргументированно.
Самый лутший это Профит/Просадка, еще использую поиск макс баланса, а саму по себе просадку минимальную никогда даже не искал (т.к. она минимальна когда сделок ноль). Остальные имеющиеся варианты вообще необьективны. Что касается Профит/Просадка. С ним есть трудности. Первую я описал, это при низком количестве сделок у вас будет завышеный результат (соотношение слишком хорошее получится). Вторая трудность, это та, что этот подход будет зависим от количества истории на котором вы тестируете. Т.е. если вы протестируете за 10 месяцев. У вас может получится ПрофитПросадка равная 2. (10к сумарного профита против 5к просадки) А если вы прогоните за 20 месяцев. То у вас может выйти ну например 4. (сумарный профит возрастет до 20к, а просадка останется таже, 5к). Чем больше будет период, тем лутше будет результат вобщем... Впрочем это логично, т.к. стабильность МТС автоматически будет учитыватся. Но опять таки, сравнивать две разные МТС котороые оптимизировались за разные период по этому критерию будет нецелесообразно (но это вовсе не помеха). По каким параметрам еще... Даже не заню. Сложно их сразу формализовать т.к. их приходится выискивать, и внимательно наблюдать за графиком. Могу сказать сразу что УЖАСНО не хватает отчетности по месяцам. Т.е. чтобы после теста эксперта я мог видеть итог кажого месяца скажем в виде гистограммы. Покачто я заганяю результаты итогов месяца в эксель в таблицу, и смотрю по месяцам, что они там на твоирил. В первом месяце +456 пунктов, второй +245, третий -153 и т.д. Если бы можно было задать целевой функцией стремится уменьшать разброс между месяцами, было бы вобще супер. Т.е. у нас бы в некоторых месяцах небыло бы супер профита, а в других небылобы огромных потерь. Но к сожалению я неготов вам предоставить готовую формулу для расчета, т.к. я это делаю в оснвном визуально. Интуитивно могу сказать что она должна расчитыватся на основе отклонения от среднего профита. Чем больше рывковых отклонений, тем хуже результат. Это было бы аналогом того, что после прогона эксперта мы пялимся на кривую, и оцениваем ее прямоту (анализируем почему там сливает и там зарабаывате). Что касается фильтров... Как я и написал, мне нужен только один (минимальное количество сделок), но его нет. Остальным не пользуюсь, и вобще непонимаю зачем они...
Еще раз прошу обратить внимание на проблему со своповым переоткрытием! Вы явно не вникли в суть. Привожу пример что ваш терминал сделать НЕМОЖЕТ НУ НИКАК:
Есть счет в неком банке в котором используется переоткрытие ордеров. К этому счету прикрепленна МТС использующая трейл который должен вынести СЛ в ноль при достижении некого профита. А вот тут внимание. Каким образом мы можем перенести в ноль СЛ если мы даже не знаем где находилась до этого цена открытия?.. Закодировать цену открытия в мэджик намбер ордера НЕВОЗМОЖНО. Т.к. если у нас есть слиппаж, то не факт что мы откроемся по той цене что надо. Второе, мы можем после того как открылся ордер записать его цену открытия в глобальную переменную. Но. Уже столкнулся с неудобством этого подхода. Особенно если гдето терминал теряет доступ к ДЦ (а причины этого бывают поверте), и приходится включать моментально дублирующий терминал в другом месте (как правило он уже висит на готове). Сразу проблема, у нас нету глобальных переменных которые есть в терминале который работал но "потух". Приходится самому смотреть и раставлять их, я уже молчу что иногда такой возможности даже нет. Вобщем, геморой. И это все из за того что я немогу узнать по какой же цене у меня изначально открылся ордер до всяких переносов. Подумайте сами. У вас есть в ордера такое поле как "коментарий" который для МТС никакой фактически ценности неимеет и через который можно разве что передать привет брокеру или поздравить его с днем рождения, но в тоже время нет возможности отследить изначальную цену ордера без каких либо трудностей.
Есть счет в неком банке в котором используется переоткрытие ордеров. К этому счету прикрепленна МТС использующая трейл который должен вынести СЛ в ноль при достижении некого профита. А вот тут внимание. Каким образом мы можем перенести в ноль СЛ если мы даже не знаем где находилась до этого цена открытия?.. Закодировать цену открытия в мэджик намбер ордера НЕВОЗМОЖНО. Т.к. если у нас есть слиппаж, то не факт что мы откроемся по той цене что надо. Второе, мы можем после того как открылся ордер записать его цену открытия в глобальную переменную. Но. Уже столкнулся с неудобством этого подхода. Особенно если гдето терминал теряет доступ к ДЦ (а причины этого бывают поверте), и приходится включать моментально дублирующий терминал в другом месте (как правило он уже висит на готове). Сразу проблема, у нас нету глобальных переменных которые есть в терминале который работал но "потух". Приходится самому смотреть и раставлять их, я уже молчу что иногда такой возможности даже нет. Вобщем, геморой. И это все из за того что я немогу узнать по какой же цене у меня изначально открылся ордер до всяких переносов. Подумайте сами. У вас есть в ордера такое поле как "коментарий" который для МТС никакой фактически ценности неимеет и через который можно разве что передать привет брокеру или поздравить его с днем рождения, но в тоже время нет возможности отследить изначальную цену ордера без каких либо трудностей.
Пост удалён, неинформативный какой-то вышел.
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
1) Вопрос касательно ГА. Штука удобная, но выбор критериев оптимизации несовсем нравится.... Я понимаю что можно сделать подбор параметров оптимизации через фильтры... Но.. Можно ли как то сделать чтобы целевую функцию вписывать формулой?... Допустим что бы можно было написать Баланс/Дродаун. Или чтото наподобии. Т.е. в итоге мы будем получать один критерий, но не из списка имеющихся.
2) Этот вопрос с другой оперы. Суть такова. Возникают проблемы когда нам нужно мониторить которые переоткрытились по свопу. Проблема заключается в том что мы теряем OrderOpenPrice изначальный. Я понимаю что его можно записать в глобал вариэйбл и потом искать через мэджик ордера. Но это не есть гуд. Потомучто мы привязываемся к терминалу. Т.е. если мы хотим включить МТС в другом терминале, а у нас висят ордера которые уже переоткрывались, и занчит мы в другой терминал обязаны будем перенести переменные (причем жилательно без ошибок). Что как видно с вида, весьма каряво. Второй способ, прописать непосредственно в ордере цену его открытия (допустим закодировать его мэджике) некатит. Т.к. если мы кидаем ордер со слипажжем 4 пункта, то мы наверняка незнаем по какаой цене он откроется. А после того как оредер открылся, мы в нем модифицировать переменные и мэджики не можем. Поэтому очень хотелось чтобы вы добавили такую функцию как OrderOriginalOpenPrice() (например так..) в которой будет сохранятся изначальная цена открытия ордера.