Облако, "Turbo"-режим генетической оптимизации - страница 4

 

Стоп.

Погодите.

1. В наличии 10000 облачных агентов.

2. Популяция равна 100 особей.

3. Генерим (операторами ГА) 10000 дочерних особей от 100 материнских.

4. Отправляем дочерних особей в облако.

5. Ждем, пока не придут 100 ответов для создания и вселения в популяцию.

6. Вселяем.

7. Генерим (операторами ГА) n-ое количесто дочерних особей от 100 материнских для уже выполнивших задачу и ждущих новую.

8. Отправляем дочерних особей в облако.

9. Ждем, пока не придут 100 ответов для создания и вселения в популяцию.

10. Вселяем.

11. повторить п. 7.


Разве сейчас не так? по такой схеме без разницы степень тормазнутости отдельных агентов облака - все результаты от каждого агента так или иначе придут на локальную машину и будут ранжированы.

Куда ещё улучшать то? Или туплю. Одно из трёх.

 
На пункте 4 в облако отсылаете 10 000 заданий, чтобы взять всего лишь 100?
 
Renat:
На пункте 4 в облако отсылаете 10 000 заданий, чтобы взять всего лишь 100?

что бы обратно взять.

да, так. цыфери взяты, извините, от балды.

смысл - получаем готовые задания не дожидаясь остальных (остальные все равно придут рано или поздно и будут предоставлены на ранжирование)

 
joo:

что бы обратно взять.

да, так. цыфери взяты, извините, от балды.

смысл - получаем готовые задания не дожидаясь остальных (остальные все равно придут рано или поздно и будут предоставлены на ранжирование)

Это ничего, что придется заплатить деньгами в 100 раз дороже, послав на расчет 10 000 задач вместо 100?

Нет, господа, такие упрощения никто принимать не будет. От реальности не отрывайтесь.

 
Renat:

Это ничего, что придется заплатить деньгами в 100 раз дороже, послав на расчет 10 000 задач вместо 100?

Нет, господа, такие упрощения никто принимать не будет. От реальности не отрывайтесь.

Погодите. Это же утрированные цифры.

Заранее же известно, сколько нужно будет проделать расчетов для генетической оптимизации (как впрочем и при полном переборе). Столько и будет платить заказчик, а как иначе. Так сейчас.

 
joo:

Погодите. Это же утрированные цифры.

Заранее же известно, сколько нужно будет проделать расчетов для генетической оптимизации (как впрочем и при полном переборе). Столько и будет платить заказчик, а как иначе. Так сейчас.

Заранее ничего не известно. Генетика позволяет свернуть в 10 000-15 000 проходов потенциально возможное поле расчетов типа 10 в надцатой степени вариантов.

Для достижения такой эффективности есть метод последовательного приближения методом вывода наилучших генов (совокупность цепочки параметров). Метод основан на последовательном (это критично!) улучшении, что требует ожидания результатов очередного поколения.

В этой ветке предлагают не ждать окончания очередной популяции, а бежать вперед, рассчитывая то, что еще не выбрано (это важно! выбираются наилучшие особи, а тут даже популяция не завершена). В общем, вы неправы.

 

Я часто (в том числе и тут) слыхал упования на природу. Господа, природа не есть критерий истинности. Да, за миллиарды лет эволюции природа подобрала робастый алгоритм. Но это не значит что поиск наилучшего алгоритма закончен. И применяя мат.методы можно природный алгоритм улучшить (имхо).

В данном случае используется бинарный ГА, как наиболее оптимальный для той задачи что стояла. Оптимальность алгоритма означает его уязвимость при смене параметров решения. Ну нельзя бинарку вот так просто курочать.

UGA не настолько оптимален, но в этом его преимущество (хотя и его отбалды нельзя шатать). Но всё же, у него можно перепрыгивать через поколения и женить гены разных поколений, он выстоит.

Когда пишите посты типа "а давайте", делайте пожалуйста акцент на алгоритм.

 
Renat:

А чем 1024 параметра не устраивают?

Кастомной генетики не будет, так как существующей хватает выше крыши и нет массового спроса.


Renat 2013.05.04 14:45

Есть желающие прямо поучаствовать?

С нас финансирование и общее управление. Заведем общий проект в MQL5 Storage и можно начинать.


Зря вы выеживаетесь, MetaDriver  дело говорит, особенно насчет конвейерной схемы.

Лет через пять все равно придете к этому.


 

У меня 2 компа, каждый по 8 ядер. На котором стоит терминал, уже староват и слабоват, скорость обработки данных раза в два ниже второго, который используется как удаленный.

В начале процесса оптимизации используются все 16 ядер и естественно разницы где происходит обработка быстрее или медленнее нет, пока на локальном идет один прогон, на удаленном - 2. При этом никто никого не тормозит.

Тормоза начинаются потом, когда количество заданий - меньше 8. Обработка идет целиком на локальном слабом компе. Скоростной при этом простаивает. А хотелось бы, чтоб тестер додумался запускать задания на более сильном компьютере. Это как пример, теперь про облако.

А не лучше ли анализировать скорость проходов в облаке и когда количество клиентов, необходимых для обработки значительно падает, на основе анализа, давать эти задания товарищам, которые были быстрее на предыдущих этапах, т.о. все будут в деле, слабые на начальных этапах обработки, а сильные ближе к концу. Значит тормознутые компы в конце теста просто не будут участвовать в процессе.

 

Мы не закончили.  Отвечу кодом. Через недельку. Смоделирую и выложу.

:)

Причина обращения: