MetaTrader 5 Strategy Tester! - страница 55
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
К сожалению, у меня нет времени на это. Очень занят на порядки более сложными темами. В форуме отвечаю на краткие вопросы.
Режим мат расчетов в тестере предназначен для распараллеливания вычислений на множестве ядер, ферме или клауде.
ГА-алгоритм у Вас не параллельный, а последовательный. Как и в других мат пакетах. Поэтому смысл ГА на облаке сводится только к тому, чтобы ускорить выполнение каждой одиночной итерации. Но скорость всего облака в ГА режиме будет сверху ограничена скоростью самого медленного агента в Облаке. Ну алгоритм ГА такой у всех, а не только у Вас. Там без предыдущих итераций никуда нельзя. Все последовательно и параллелится минимально.
Я тоже соглашусь, что если ресурсы простаивают из-за слабого звена, то такой алгоритм нельзя назвать эффективным.
Вот если брать аналогию с ГА в живой природе, то там ведь нет такого. Особи не рождаются все одновременно, и не умирают все одновременно. Они существуют параллельно и независимо. Просто в какие-то моменты происходят случайные скрещивания, в какие-то моменты - случайные умирания, и т.д. Почему бы не реализовать эту идею, которая явно эффективней.
ГА-алгоритм у Вас не параллельный, а последовательный. Как и в других мат пакетах. Поэтому смысл ГА на облаке сводится только к тому, чтобы ускорить выполнение каждой одиночной итерации. Но скорость всего облака в ГА режиме будет сверху ограничена скоростью самого медленного агента в Облаке. Ну алгоритм ГА такой у всех, а не только у Вас. Там без предыдущих итераций никуда нельзя. Все последовательно и параллелится минимально.
Смысл облака - в ускорении за счет выполнения множества задач за один проход, это распараллеливание на уровне популяции, то есть вся популяция загоняется в облако и каждая особь выполняется отдельно на своём агенте.
Последовательность только в генерации популяций. За раз в облако передается что то около 256 особей. Тут есть некоторые моменты, которые невозможно победить, уменьшать размер популяции нецелесообразно, так как снизится производительность и сравняется выйгрыш с посравнению с облачным орехедом. Поэтому действительно, облако использовать целесообразно только при достаточно долгом выполнении одиночного теста. Но практика показывает, что использование облака слишком накладна и по деньгам и по скорости выполнения.
Практика показывает, что гораздо эффективнее делать чаще генетические операции, чем увеличивать во столько же раз популяцию. То есть выгоднее популяцию в 10 особей провести через 25 эпох, чем за одну эпоху провести 250 особей. Но уменьшение популяции приведет к снижению эффективности облака на "лёгких" задачах, а сложные выполнять сейчас слишком дорого. Таким образом, штатный алгоритм в связке с организацией облачных вычислений увяз таким образом в погоне за абсолютной универсальностью.
Я тоже соглашусь, что если ресурсы простаивают из-за слабого звена, то такой алгоритм нельзя назвать эффективным.
Вот если брать аналогию с ГА в живой природе, то там ведь нет такого. Особи не рождаются все одновременно, и не умирают все одновременно. Они существуют параллельно и независимо. Просто в какие-то моменты происходят случайные скрещивания, в какие-то моменты - случайные умирания, и т.д. Почему бы не реализовать эту идею, которая явно эффективней.
Тем самым вы увеличите объем просчетов, но безрезультатно. Бесцельно по сути, так как вы не дождались скрещенного поколения, а выстрелили в молоко.
Можно конечно предиктивно на неполном результате текущей считаемой популяции делать попытки смешения, но там промахов будет запросто близко к 100%. В общем, увеличение объема вычисления налицо, а ускорения - нет.
Мы предпринимаем ряд защитных мер в клауде и для генетических задач выбираем особо мощных и быстрых агентов, чтобы решить проблему ожидания самого медленного агента. У кого реально в клауде были серьезные проблемы с ожиданием медленных агентов при ГА?
Я тоже соглашусь, что если ресурсы простаивают из-за слабого звена, то такой алгоритм нельзя назвать эффективным.
Вот если брать аналогию с ГА в живой природе, то там ведь нет такого. Особи не рождаются все одновременно, и не умирают все одновременно. Они существуют параллельно и независимо. Просто в какие-то моменты происходят случайные скрещивания, в какие-то моменты - случайные умирания, и т.д. Почему бы не реализовать эту идею, которая явно эффективней.
Попробуйте, реализуйте.
Парадокс заключается в том, что механизмы природы не всегда являются самыми эффективными из возможных, они лишь такие, какие могут быть "реализованы" в живой природе. Естественный ГА в живой природе не самое лучшее и универсальное решение из возможных.
Практика показывает, что гораздо эффективнее делать чаще генетические операции, чем увеличивать во столько же раз популяцию. То есть выгоднее популяцию в 10 особей провести через 25 эпох, чем за одну эпоху провести 250 особей. Но уменьшение популяции приведет к снижению эффективности облака на "лёгких" задачах, а сложные выполнять сейчас слишком дорого. Таким образом, штатный алгоритм в связке с организацией облачных вычислений увяз таким образом в погоне за абсолютной универсальностью.
В утверждении ошибка в категорически заниженном количестве особей.
Если делать популяции в 10 (да и вообще меньше 128) особей, то это будет полная профанация и дикий дребезг генов/параметров. В наших условиях надо работать с 256 особями в популяции как минимум.
Наш ГА ни в чем не увяз и работает эффективно. Ни один человек не смог публично опровергнуть это за последние 10 лет, что мы развиваем свой ГА.
И претензий к нашему генетическому алгоритму так и не было.Таким образом, задача состоит из 705 символов, каждый из символов может иметь 60 вариантов (строка 705 символов, ключ 60 символов).
Соответственно максимально возможное число ФФ может выдать: 705, что означает 100% совпадение.
Прошу учесть, что это только мы знаем, какое максимальное число может выдать ФФ, поэтому ориентирование на число 705 в алгоритме недопустимо. Алгоритм должен считать, что максимальное число в ФФ ничем не ограничено и может быть любым.
ps. шибко сомневаюсь, что какой бы то ни было алгоритм сможет набрать больше 200 совпадений, это унриал... тем более будет интересно.
В утверждении ошибка в категорически заниженном количестве особей.
Если делать популяции в 10 (да и вообще меньше 128) особей, то это будет полная профанация и дикий дребезг генов/параметров. В наших условиях надо работать с 256 особями в популяции как минимум.
Наш ГА ни в чем не увяз и работает эффективно. Ни один человек не смог публично опровергнуть это за последние 10 лет, что мы развиваем свой ГА.
Я об этом и написал - в условиях облака 256 особей это минимум, который позволяет покрывать оверхед, поэтому так и сделано. Но реально необходимое количество особей в популяции действительно намного меньше. Есть порог, при котором снижается эффективность, конечно, и этот порог зависит от многих факторов, в том числе и из за облака, для штатного порог это 256 особей. Красивое число, кстати, здесь тоже не случайно, не 200, не 300, а 256.
За 10 лет никто, да, потому что штатный алгоритм действительно хорош и потому что не проводились полномасштабные сравнительные тесты.
Тесты проведем. Докажем или опровергнем первенство штатного алгоритма, это же только на пользу пойдет всем.
Никто не обсуждает сейчас собственно сам тестер и облако - они безусловно вне конкуренции, но оптимизатору, полагаю, есть куда ещё стремится.
Вот простой тест с генетическим алгоритмом по максимуму баланса на Moving Averages: EURUSD H1, 2016.01.01-2016.11.21, все тики, MetaQuotes-Demo
На локальном компе с 24 ядрами показал оценочное время расчета около 32 минут (тест до конца не довел, время бы меньше получилось, так как часть расчетов пропустилась бы как дубли). В клауде показал точно 3 минуты (тест прошел до конца).
Причем важно, что при работе в клауде не было никаких тормозов и все результаты возвращались быстро. Это доказывает, что стратегия выбора быстрых агентов у нас работает хорошо и проблемы ожидания самого медленного агента практически нет.