Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Тестовый скрипт по первому варианту исполнения алгоритма:
Для такой простой функции, Вы чересчур усложнили интерфейс. Много ненужного экспорта, а нужных вещей наоборот не хватает. Разобрался в Вашем коде не с первого раза, представляю что чувствуют люди не так хорошо владеющие программированием.
Сейчас подумаю и предложу свой вариант упрощенного экспорта и работы тестового скрипта.
Возможно, "эволюционный" подход нахождения значений параметров уравнения ФФ, создан не столько с целью повышения эффективности поиска значений, сколько для программного моделирования процесса эволюции.
Ну в том виде, каком эволюцию представляют ученые...
Уж больно подход последователен в своем соответствии всем эволюционным канонам...
Пропозиция:
1. фитнес-функция принимает массив параметров типа double и возвращает число тем больше, чем лучше подобраны параметры. Прототип фитнес-функции следующий:
2. Фитнес-функция обладает определенными параметрами, которые указываются в структуре FitnessParams. Описание структуры дано ниже:
3. Фитнес функция и ее параметры защищены от внешнего воздействия и находятся в независимой библиотеке ..\\Scripts\\FF\\FF.ex5 Значения параметров фитнес-функции, как и сам ее алгоритм задается в момент комплиляции независимым рефери и больше не может быть кем-либо изменен.
4. Пользовательский алгоритм оптимизации и проверяющий скрипт могут узнать параметры фитнес-функции. Для чего в файле Export.mqh содержаться необходимые прототипы этой функции и ее параметров. Для получения параметров FF используется функция экспорта параметров, также размещенная в ..\\Scripts\\FF\\FF.ex5:
void GetFitnessParams(FitnessParams& params);
5. Пользовательский алгоритм оптимизации находится в отдельной, закрытой пользовательской библиотеки ..\\Scripts\\FF\\UserFindExtremum.ex5 и компилируется отдельно, на стороне пользователя. В библиотеке пользователя должна быть экспортирована функция FindExtremum. Эту функцию будет вызывать проверяющий скрипт. Ниже представлен полный прототип функции:
6. Проверяющий скрипт загружает в свое адресное пространство библиотеку фитнесс-функции ..\\Scripts\\FF\\FF.ex5 с ее параметрами, и библиотеку участника по поиску экстремума ..\\Scripts\\FF\\UserFindExtremum.ex5. После чего вызывает функцию участника FindExtremum.
7. После отработки функции участника, проверяющий скрипт запрашивает параметры фитнес-функции, в которых содержится максимальное найденное значение функцией участника, а также количество вызовов, которое потребовалось для нахождения этого максимума. На основании этих данных формируется отчет о результате участника в виде таблицы:
В следующем посте будут приложены необходимые файлы и пример использования
Файл Export.mqh - общий для всех участников список доступных функций и структура параметров
Файл FF.mq5 - пример фитнес-функции в виде библиотеки.
Файл TestFF.mq5 - проверяющий алгоритм в виде скрипта
Файл UserFindExtremum.mq5 - пользовательская функция поиска экстремума в виде библоитеки. В качестве примера используется случайный поиск
Файл Export.mqh - общий для всех участников список доступных функций и структура параметров
Файл FF.mq5 - пример фитнес-функции в виде библиотеки.
Файл TestFF.mq5 - проверяющий алгоритм в виде скрипта
Файл UserFindExtremum.mq5 - пользовательская функция поиска экстремума в виде библоитеке. В качестве примера используется случайный поиск
Для такой простой функции, Вы чересчур усложнили интерфейс. Много ненужного экспорта, а нужных вещей наоборот не хватает. Разобрался в Вашем коде не с первого раза, представляю что чувствуют люди не так хорошо владеющие программированием.
Сейчас подумаю и предложу свой вариант упрощенного экспорта и работы тестового скрипта.
Почему не нужных?
Каких нужных не хватает?
Ведь не просто для того, что бы максимально усложнить жизнь участникам так всё я сделал, и не первый день всё обдумывалось и даже не второй.
Почему не нужных?
Каких нужных не хватает?
Ведь не просто для того, что бы максимально усложнить жизнь участникам так всё я сделал, и не первый день всё обдумывалось и даже не второй.
Андрей, я не знаю как другие, но лично мне, пример Василия понравился больше. Без обид. Это просто мое субъективное восприятие...
Чтобы было честно, предлагаю поставить вопрос о выборе интерфейса подключения (Вашего или Василия) на голосование.
Как Вы считаете?
Андрей, я не знаю как другие, но лично мне, пример Василия понравился больше. Без обид. Это просто мое субъективное восприятие...
Чтобы было честно, предлагаю поставить вопрос о выборе интерфейса подключения (Вашего или Василия) на голосование.
Как Вы считаете?
Почему не нужных?
Каких нужных не хватает?
Ведь не просто для того, что бы максимально усложнить жизнь участникам так всё я сделал, и не первый день всё обдумывалось и даже не второй.
В Вашем примере задача поиска частично делегируется проверяющему скрипту. Это неправильно. Скрипт проверки должен вызвать поиск и проверить его результат и ничего больше.
Не все параметры ФФ доступны. Например, как получить шаг параметров (значение 0.1), возможный максимум и минимум? Это конечно замечательно, что каждый пользователь должен прочитать этот форум и понять, что шаг оказывается равен 0.1, минимум -10.0 а максимум +10.0, после чего ввести эти константы в свой код, после чего надеятся, что ФФ функция думает также. Но по-хорошему так не делается.
Многие экспортные функции, вроде ServiceFunc1 используются лишь в специфических алгоритмах поиска. Например в случайном поиске их юзать не надо. Тогда зачем пользовательская библиотека должна их экспортировать? Достаточно разделить задачу тестирования с задачей непосредственного поиска что бы понять, что вся эта сложная комбинация экспортных функций просто не нужна.
Есть еще много моментов, которые делают не нужные надстройки.
Чем конкретно нравится больше?