Облако, "Turbo"-режим генетической оптимизации - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если писали, то очень странно слышать, что вы готовы не глядя выбросить N% заботливо отобранных особей в NN поколении.
Я писал реализации. И утверждаю то же самое. Единственный (но существенный) нюанс: я писал под ядра OpenCL, а потому позволял себе очень большие популяции (очень высокую избыточность).
Хорошо, давайте не будем отбрасывать. Утверждаю, однако, что смешение поколений не приведёт ни к каким пагубным результатам.
Распиши по шагам алгоритм твоего варианта облачного ГА:
1... 2... и т.д.
Что бы можно было прикинуть, стоит овчинка выделки или не.ОК. Строим конвейер без отбрасывания. Конвейр многопоточный, естественно, асинхронный.
В простейшем случае четыре типа компонентов.
1. собсно ГА.
2. Буфер поступивших из облака решений.
3. Сервер распределения заданий и сбора решений от агентов.
// Дальше в схеме предполагается, что у сервера только один клиент, что, естественно, не так, но упрощает рассуждения не позволяя уйти от сути.
4. Агенты.
Теперь схема взаимодействия. Начнём с конца.
4. Агенты: Получают задания от сервера, выполняют, отравляют решения на сервер. Всё как сейчас, без изменений.
3. Сервер заданий. Получает от ГА пакеты заданий, распределяет по сети агентов, подбирает решения, отправляет в буфер. Работает проще чем сейчас (следовательно надёжнее), поскольку от него не требуется аналитической деятельности и наблюдения за работоспособностью агентов в процессе расчёта.
// Невыполненные задания, если их таки отслеживать (:из чистой жадности, имхо:) можно просто раздавать по сети агентов повторно, как только выявлен факт невыполнения.
2. Буфер решений. Просто накапливает решения по мере поступления. Получает их от сервера заданий, отдаёт по запросу ГА.
1. Генетический процессор. Здесь есть изменения, поэтому распишу подробнее:
А) Первое поколение генерится как обычно, но с небольшой избыточностью (к примеру 105% от необходимого для следующего поколения).
Б, В, Г, Д, ...) В цикле: При накоплении в буфере достаточного (для генерации очередной эпохи) количества выполненных заданий просто забирает их и обрабатывает по обычной схеме, т.е. сортирует, селекционирует и (если не достигнут критерий завершения оптимизации) генерирует новое поколение, которое немедленно отсылается серверу заданий.
Собсно всё. Все существующие блоки если и изменяются, то только в сторону упрощения.
Естественно, появляются новые нюансы. Например озвученный в первом посте феномен приоритета быстрых реализаций в ущерб медленно работающим. Кроме того появляются новые тонкости с временным прерыванием оптимизации с возможностью продолжения (из за размывания понятия "поколение"). Но в целом всё это решаемо, и выделки безусловно стоит, ибо прирост в скорости огромен.
--
Примерно так. Ещё раз повторюсь:
1. из за существующих нюансов (выявленных и ещё неизвестных), режим лучше сделать дополнительным к уже существующему набору, дабы сохранить у юзера доступ к медленной старой схеме, которая уже неплохо проверена на опыте и к тому же незаменима при очень существенной зависимости скорости выполнения от конкретной реализации генотипа.
2. Я плачу облаку за скорость, а не точность. И готов платить больше на 10 и даже 20% за двухкратное ускорение. А не те 2-3% которые реально необходимы при новой схеме. В случае же повторения невыполненных заданий (без отбрасывания) никаких дополнительных расходов в облаке (у агентов) вообще не видно.
--
ps. Всем персональные приветы и благодарность за участие в обсуждении. :)
А вы сами писали реализацию генетики?
Если писали, то очень странно слышать, что вы готовы не глядя выбросить N% заботливо отобранных особей в NN поколении.
/// Уф, всё таки разгипнотизировался. Ренат, не давите авторитетом, пожалуйста, а то потом ваши глюки приходится из своей головы долго выковыривать. :))
Таки ничего там (в заданиях) заботливо не отобрано. Заботливо отобраны только родительские особи, использованные для генерации очередной порции мусора очередного поколения заданий.
Дык никуда эти родители и неотбрасываются, где были там и остаются. А в очередном поколении распределение "гениальных/тупых" отнюдь не в пользу первых.
Поэтому снова ставлю на обсуждение схему с отбрасыванием, ибо она практически готова и затрат требует ноль с половиной копеек. В отличии от конвеера, который, конечно, лучше, но чуть сложнее.
/// Уф, всё таки разгипнотизировался. Ренат, не давите авторитетом, пожалуйста, а то потом ваши глюки приходится из своей головы долго выковыривать. :))
Таки ничего там (в заданиях) заботливо не отобрано. Заботливо отобраны только родительские особи, использованные для генерации очередной порции мусора очередного поколения заданий.
Дык никуда эти родители и неотбрасываются, где были там и остаются. А в очередном поколении распределение "гениальных/тупых" отнюдь не в пользу первых.
Поэтому снова ставлю на обсуждение схему с отбрасыванием, ибо она практически готова и затрат требует ноль с половиной копеек. В отличии от конвеера, который, конечно, лучше, но чуть сложнее.
Вы хотите "выбросить случайные N% результатов расчетов" или "перенести нерасчитанные %N на прошлых генерациях особи в последующие генерации"?
Если перенести нерасчитанные варианты в последующие, то можно поломать методику скрещивания. То есть "никуда эти родители и неотбрасываются, где были там и остаются" не получится.
Ускорить мы можем, просто агрессивнее раза в 2-3 разогнать уровни оценки тормозов. Мы протестируем такой подход.
Вы хотите "выбросить случайные N% результатов расчетов" или "перенести нерасчитанные %N на прошлых генерациях особи в последующие генерации"?
Если перенести нерасчитанные варианты в последующие, то можно поломать методику скрещивания. То есть "никуда эти родители и неотбрасываются, где были там и остаются" не получится.
Ускорить мы можем, просто агрессивнее раза в 2-3 разогнать уровни оценки тормозов. Мы протестируем такой подход.
А вы сами писали реализацию генетики?
Если писали, то очень странно слышать, что вы готовы не глядя выбросить N% заботливо отобранных особей в NN поколении.
Не нужно забывать и о том, что небрежность в генетике сразу же приведет к появлению заявлений - "да у них генетика грязно считает, локальные экстремумы может пропускать на ровном месте".
Скорость мы знаем как повысить более чистыми методами, я уже писал.
Случайность сильно отличается от осознанной потенциальной потери лучших результатов надцатого поколения.
...
Скорость мы знаем как повысить более чистыми методами, я уже писал.
Гуманист, однако.
Ренат, а как обстоят дела с кастомной генетикой? Стринго как-то обещал....
Гуманист, однако.
Ренат, а как обстоят дела с кастомной генетикой? Стринго как-то обещал....
А чем 1024 параметра не устраивают?
Кастомной генетики не будет, так как существующей хватает выше крыши и нет массового спроса.
А чем 1024 параметра не устраивают?
Кастомной генетики не будет, так как существующей хватает выше крыши и нет массового спроса.
Как то хотца 10 лям параметров, своя тянет а в вашу ну ни как не впихнуть.
ЗЫ опять же, у вас однокритериальная, это вчерашний день.
Этот вопрос касается не только облака, но и удалённых агентов. Ибо скорость тестирования определяется самым медленным агентом, и если проходы занимают десятки минут (а это элементарно - пяток инструментов за 2-3 года), то простои по ожиданию всех результатов в итоге составляют приличное время.
Предложение MetaDriver кажется разумным.