Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ? - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
По всему видно, что это Вы совершенно не поняли сути вопроса. Посему Ваш чрезмерно самоуверенный "совет" - в топку!
В топку не получится ))
Ваш дилетантский вопрос прозвучал, мой самоуверенный совет тоже.
Вы не модератор и не администратор, поэтому не вам решать - кого в топку.
Не должен человек понимать даже базы генетических алгоритмов для того, чтобы нажать кнопку оптимизация. просто нажать кнопку.
Не, ну так мы до сушки котов в микроволновке дойдем.
Не нужно поощрять эту потреблядскую позицию "я нажал кнопку, почему не работает??!".
ps: к использованию генетики мой пост отношения не имеет.
Вы не правы в корне.
Ещё раз повторюсь, как пользователь я вижу: Оптимизация Медленная/Быстрая.
Всё, дальше мне не интересно. Ни в качестве глубоких знаний, ни в свете фундаментальных вещей.
Это ваша жизненная позиция? Боюсь что такой дилетантский подход к вещам принесёт вам немало проблем. Особенно в вопросах финансов. Не желаете разбираться - будете кормом для тех, кто разбирается.
Если написано "быстрая" и "медленная", то у здравомыслящего человека первым делом должна возникнуть мысль: а зачем тут вообще присутствует "медленная", если те же самые результаты можно получить быстро? ...или не те же самые?.. надо разобраться...
Но каждому своё.
Всё правильно.
Только я склоняюсь к мнению, что ограничения нужно устранять, по мере возможности, силами разработчиков. То же и со слабыми сторонами.
Я стараюсь вообще не использовать генетическую оптимизацию. Но коль уж приходится, то совершенно не хочется влазить в дебри этих алгоритмов. Ну не для пользователя это.
Как пример, вот сижу я за компом, клацаю по клавишам, и мне совершенно всё-равно что происходит от момента нажатия до появления символа на экране. Совсем не интересно как работает процессор, видеокарта, винты, кулера, как они взаимодействуют. Это тоже не для простого пользователя.
Ну, так именно поэтому - ты должен понимать, что нажатие на кнопку символа - предназначено для получения одного символа. Причем, есть ограничения, скажем, в скорости нажатия. А ты пытаешься нажать на кнопку 50 раз в секунду, и возмущаешься, что вывелось не 50 символов.
Вопрос - способность воспринять 50 символов в секунду - надо ли устранять это ограничение ? Не окажется ли для большинства пользователей это наоборот, ухудшением, когда дребезг контактов будет восприниматься за символы ?
Не должен человек понимать даже базы генетических алгоритмов для того, чтобы нажать кнопку оптимизация. просто нажать кнопку.
С чего бы это ?
Если он не должен понимать - то он не должен и спрашивать "почему у меня получилась фигня". Раз получилась - значит "просто получилось". Так было задумано.
Любой инструмент требует определенного уровня понимания. Это не исключает использования "черных ящиков", но даже при использовании "черных ящиков" необходимо четко понимать основные закономерности, по которым данный "черный ящик" функционирует.
Господа-товарищи!
Мы скатываемся на обсуждение кто что понимает/не понимает и надо/не надо ли это. А вопрос по существу отошёл на задний план.
Я не знаю механизмов генетики, так что приложите некоторое усилие чтобы понять, что я хочу сказать.
Есть 117649 вариантов (проходов). Из них допустимых - только 1953. В принципе, по настоящему недопустимых - 1 (000000)!!! А 115695 - это повторения. Разные вариации из тех 1953-х "допустимых". Для экономии времени и ресурсов я их и исключаю по INIT_PARAMETERS_INCORRECT.
Далее. Генетика собирает первую популяцию из 512 особей. Так?
И в эту популяцию сразу попадает 502 "недопустимых" особи. 10 рабочих особей мало. Согласен.
Но 512 - это только 1/4 от 1953 (приблизительно).
Не вдаваясь в дальнейшее копание в генетике, мне не понятно, почему нельзя собрать первую популяцию только из "допустимых" параметров?
И, по большому счёту, что мешает и последующие популяции собирать только из валидных параметров???Не, ну так мы до сушки котов в микроволновке дойдем.
Не нужно поощрять эту потреблядскую позицию "я нажал кнопку, почему не работает??!".
Кроме всего прочего, лично я, в основном, использую INIT_PARAMETERS_INCORRECT только в режиме оптимизации именно для отсеивания не недопустимых, в прямом смысле слова параметров, а просто лишних проходов.
Как пример:
Так вот, если при тесте и при работе советника при использовать_параметр = false его параметры совершенно не имеют никакого значения, то при оптимизации перебор этих параметров просто лишний, поэтому производится выход по INIT_PARAMETERS_INCORRECT кроме единственного прохода с изначальными значениями. Это экономит кучу времени. Ведь на один валидный проход приходится целая куча бесполезных. А генетика воспринимает отсеивание бесполезных проходов как грубую ошибку.
Разрабы, вместо того чтобы как-то решать эту проблему, посылают изучать эту самую генетику, к тому же с наложением бана. Чтобы было время изучать, я так понимаю.
А я ещё раз повторю: пользователю знать как работает генетика нет нужды! А вот найти решение этой проблемы - задача для разработчиков.
Кроме всего прочего, лично я, в основном, использую INIT_PARAMETERS_INCORRECT только в режиме оптимизации именно для отсеивания не недопустимых, в прямом смысле слова параметров, а просто лишних проходов.
Как пример:
Так вот, если при тесте и при работе советника при использовать_параметр = false его параметры совершенно не имеют никакого значения, то при оптимизации перебор этих параметров просто лишний, поэтому производится выход по INIT_PARAMETERS_INCORRECT кроме единственного прохода с изначальными значениями. Это экономит кучу времени. Ведь на один валидный проход приходится целая куча бесполезных. А генетика воспринимает отсеивание бесполезных проходов как грубую ошибку.
Разрабы, вместо того чтобы как-то решать эту проблему, посылают изучать эту самую генетику, к тому же с наложением бана. Чтобы было время изучать, я так понимаю.
А я ещё раз повторю: пользователю знать как работает генетика нет нужды! А вот найти решение этой проблемы - задача для разработчиков.
У Вас 4 параметра, вот Вам и нужно организовать как то работу этих 4х параметров только с корректными значениями, тогда от генетики может быть толк.
Есть 117649 вариантов (проходов). Из них допустимых - только 1953. В принципе, по настоящему недопустимых - 1 (000000)!!! А 115695 - это повторения. Разные вариации из тех 1953-х "допустимых". Для экономии времени и ресурсов я их и исключаю по INIT_PARAMETERS_INCORRECT.
лично я, в основном, использую INIT_PARAMETERS_INCORRECT только в режиме оптимизации именно для отсеивания не недопустимых, в прямом смысле слова параметров, а просто лишних проходов.
Вот в этом и состоит ваша ошибка. "Лишних" проходов в генетике нет. Она сама всё раскладывает по полочкам, отсеивая лишнее, за счёт чего в итоге и достигается экономия времени и ресурсов. А вы только мешаете ей.
По сути, вы противоречите сами себе. Сначала говорите, что нужно чтобы всё само работало при нажатии волшебной кнопки, без каких либо дополнительных усилий с вашей стороны. Но при этом сами же устраиваете шаманства в коде, якобы помогая алгоритму оптимизации.
Короче, теперь всё проясняется:
Сергей Таболин:
А если так:
121
то ведь итог будет как 21. А цепочка 21 повторит этот результат. Дублирование, лишнее время на, в принципе, бесполезные прогоны...
Не нужно ничего отсеивать по INIT_PARAMETERS_INCORRECT, вычисляйте 121 в соответствии с логикой вашей программы, а генетика сделает своё дело, и результат будет получен менее, чем за 1953 прохода (я надеюсь).
Если же проводить оптимизацию полным перебором, тогда конечно лишние проходы не нужны. Можно ввести дополнительный параметр в вашем советнике, задающий тип оптимизации. Если полный перебор, то лишние проходы отсеиваются, а если генетика - то нет. Жаль что в MQL отсутствует штатная возможность узнать тип оптимизации. Надо попросить разработчиков добавить такую функцию.