Комментарии 61
А куда баг-репорты отправлять?
Выполнил:
получил Segmentation fault. Очень хотелось посмотреть на живность.
Выполнил:
git clone git@github.com:icoz/evo.git
cd evo
qmake
make
./evo
получил Segmentation fault. Очень хотелось посмотреть на живность.
Странно. Будтье добры, сообщите пожалуйста:
1) ОС, версия
2) версию Qt
3) компилятор, версия
1) ОС, версия
2) версию Qt
3) компилятор, версия
И еще: были ли какие-либо предупреждения компилятора при сборке?
1) Arch Linux, все обновления
Linux jet 3.6.3-1-ARCH #1 SMP PREEMPT Mon Oct 22 10:23:56 CEST 2012 x86_64 GNU/Linux
2) Qt стоит из репозитория, вот этот:
extra/qt 4.8.3-4 [installed]
A cross-platform application and UI framework
3) судя по всему собирался он при помощи g++ (GCC) 4.7.2 вот лог pastebin.com/uA36ZJCs
Linux jet 3.6.3-1-ARCH #1 SMP PREEMPT Mon Oct 22 10:23:56 CEST 2012 x86_64 GNU/Linux
2) Qt стоит из репозитория, вот этот:
extra/qt 4.8.3-4 [installed]
A cross-platform application and UI framework
3) судя по всему собирался он при помощи g++ (GCC) 4.7.2 вот лог pastebin.com/uA36ZJCs
У меня тоже Arch.
Работоспособность проверялась на двух машинах с арчем: x86 и x86_64.
Работоспособность проверялась на двух машинах с арчем: x86 и x86_64.
Спасибо за работу. Как хорошо что кто-то занимается, а главное пишет про это. Скоро хаб Qt Software разбухнет от постов про клеточные автоматы.
А живность может поменять направление в котором она движется со временем? У меня на данный момент все сводится к тому, что они движутся фронтом из левого нижнего угла в правый верхний поглащая все на своем пути.
Есть еще небольшие группы двигающиеся перпендикулярно основной, но их осталось немного, видать всех сожрали.
Есть еще небольшие группы двигающиеся перпендикулярно основной, но их осталось немного, видать всех сожрали.
Спасибо, интересная тема.
Не отказался бы от готового бинарника под windows.
Не отказался бы от готового бинарника под windows.
Увы, не хватает MSVCP100.dll (возможно, что не только её).
По теме — респект автору! И за реализацию такой интересной темы, как клеточные автоматы — и за Qt.
Обработка «миром» запросов от «живности» через сигналы/слоты и впрямь напрашивалась ;)
По теме — респект автору! И за реализацию такой интересной темы, как клеточные автоматы — и за Qt.
Обработка «миром» запросов от «живности» через сигналы/слоты и впрямь напрашивалась ;)
World имеет сигнал tick(), который запускает следующий цикл работы всех Animal, получивших этот сигнал.
У Animal есть несколько сигналов, задающие действия, которые живность производит. Эти сигналы получает World и двигает/размножает/и т.д. соответствующих особей.
У Animal есть несколько сигналов, задающие действия, которые живность производит. Эти сигналы получает World и двигает/размножает/и т.д. соответствующих особей.
Странно, в прямых зависимостях её нет. В любом случае, www.microsoft.com/en-us/download/details.aspx?id=5555 должно помочь.
Сработала установка DLL по этой ссылке: www.cyberforum.ru/system-soft/thread428108.html (на WinXP 32)
Для производительности от этого скорее всего нужно будет отказываться.
Спасибо, все отлично работает.
Ноосфера что-то в последнее время полна «жизнью» :) Как раз на днях заделал такую реализацию классической версии на WebGL:
Есть редактор правил, разные кисти, даже машина Тьюринга.
Есть редактор правил, разные кисти, даже машина Тьюринга.
А не хотите добавить многопоточность, думаю можно существенно скорость эволюции поднять?
Я уже над этим думал. Но первый пункт ограничении в скорости — это отрисовка.
А второй — работа системы сигналов/слотов. Как оптимизировать её — не знаю. Только полностью переделывать архитектуру программы.
Сейчас правки можно вносить быстро — архитектура позволяет.
А второй — работа системы сигналов/слотов. Как оптимизировать её — не знаю. Только полностью переделывать архитектуру программы.
Сейчас правки можно вносить быстро — архитектура позволяет.
Я еще не вникал в код, но похоже, что как раз отрисовку можно сделать в отдельном потоке без переделки всей архитектуры. Один поток будет полностью заниматься расчетом эволюции, а второй периодически обращаться к первому, копировать текущее положение всех объектов и спокойно отрисовывать их. Время блокировки второго потока — минимально, переделка — не большая, сложность особо не увеличится.
У меня почему то и одно ядро плохо нагружает, где то 40%.
Завтра буду вникать в код и оптимизировать. Мне кажется там где то завязка на UI.
Завтра буду вникать в код и оптимизировать. Мне кажется там где то завязка на UI.
Мне кажется, что у меня что-то пошло не так %) всего 180К раундов, а уже лучшая живучесть, которая была достигнута, 350335, кажется у меня тут зародился тиранозавр :)
Ссылочка на это чудо: rghost.ru/41196763
Круто! У меня больше 36000 не было.
Когда сделаю скрещивание, то ваш индивид будет первым осеменителем!
Когда сделаю скрещивание, то ваш индивид будет первым осеменителем!
145K, max fitness 43474
Когда-то делал очень похожую штуку, но мне тогда не хватило вычислительных мощностей для интересных результатов. Вот всё думаю, а можно ли как-нибудь краудсорсить ресурсы для такой задачи? Мы бы тогда не каждый на своем компьютере запускали, а могли бы общий мир моделировать.
Но как минимум надо с оптимизировать текущий вариант и глянуть сколько мощности реально не хватает.
Тогда для начала надо отказаться от поля 256*256.
Затем придумать схему для распределенного вычисления. Самое сложное там, на мой взгляд, межнодовое взаимодействие. Плюс должен быть тогда какой-то центральный сервер, где будет само поле, по которому будут перемещаться особи. Я бы предпочел что-нибудь децентрализованное.
Да и для интереса надо бы замутить какую-нибудь вещь типа лабиринта, а не просто точки, разбросанные по полю.
Затем придумать схему для распределенного вычисления. Самое сложное там, на мой взгляд, межнодовое взаимодействие. Плюс должен быть тогда какой-то центральный сервер, где будет само поле, по которому будут перемещаться особи. Я бы предпочел что-нибудь децентрализованное.
Да и для интереса надо бы замутить какую-нибудь вещь типа лабиринта, а не просто точки, разбросанные по полю.
А что если все оставить как есть, но обмениваться только наиболее интересными индивидами между нодами? Тогда, по идее, лучшие особи будут выводиться максимально быстро :)
Вообще очень логично — вырастил у себя лучшего монстра — отправил в общий репозиторий.
При наборе достаточного количество удачных особей в репозитории каждый может стартовать уже не с нуля а засеяв мир «продвинутыми» особями (правда начав не с нуля, а используя готовых особей, скорее всего, эволюция пойдет по пути усовершенствавания удачных вариантов, а не порождению чего-то принципиально нового)
При наборе достаточного количество удачных особей в репозитории каждый может стартовать уже не с нуля а засеяв мир «продвинутыми» особями (правда начав не с нуля, а используя готовых особей, скорее всего, эволюция пойдет по пути усовершенствавания удачных вариантов, а не порождению чего-то принципиально нового)
Можно было бы еще ввести систему рейтингов — по длительности работы программы и что бы через определенный промежуток времени, например 24 часа программа отправляла результат своей работы на сервер
У знакомого нету аккаунта тут, попросил ответить вам.
Прочитал вот про вашу Evo, решил написать.
Я сам уже больше года в свободное время что-то подобное делаю.
Правда, изначальный подход отличается. Не клеточный автомат, а
попытка работать на уровне инстинктов/условных рефлексов и осознания
окружения. Соответственно особи должны не «разрабатываться в коде»,
а «воспитываться с детства».
Особенно повеселило то, что особей про себя я тоже «живностью»
называю. :)
Отличий, конечно — много. Все же я с этим, думаю, побольше сидел — уже под полмегабайта исходников написано.
Поле намного больше (с масштабированием), плотное использование
многопоточности, в т.ч. отрисовка в отдельном потоке. (Да, кстати, для
отрисовки я почти сразу использовал OpenGL — скорость значительно
выше.) Есть то самое «зрение», причем просчитывается (не)видимость за
препятствиями/стенами (и в сочетании с плавным, «не по клеткам»,
движением особей, это порядочно жрет ресурсы).
Кстати, еще совет насчет скорости — в какой-то момент понимаешь, что
все же «маловато будет». :) Я вот для некоторых блоков пытаюсь
использовать OpenCL. Но там тоже свои подводные камни — и логика
программирования другая, и нужно хранить как можно больше в памяти
видеокарты, т.к. перекачка в системную память и обратно очень
медленная (единицы гб/сек).
Ну и, у меня с самого начала была идея заточки под онлайн. :)
И те самые идеи, что сейчас пошли уже в комментах — межнодовое
распределенное взаимодействие, лабиринты, отбор лучших особей для
заселения… :))
И ощутимая часть уже написана. (Например, погонять особь по случайному
лабиринту размером с футбольное поле довольно интересно — она ведь
помнит путь, где уже ходила!)
Надеюсь, что я все же осилю это до какого-то вменяемого результата,
ибо рутины — как правильно замечено — море.
По описанию — интересно. А ваш знакомый результаты не хочет опубликовать где-нибудь? Можно без исходников, просто в виде бинарников.
Ну с таким подходом можно изначально разрабатывать модель эволюции с реализацией на CUDA. Там и производительность выше будет.
Я же не ставил целью имитацию эволюции. Я сделал набор искусственных правил, органичивающих живность, и наблюдаю как она подстраивается.
Очень интересно смотреть как реагируют стада на резкое сокращение количества травы.
Или как отдельные особи начинают резко плодиться, когда появляется большое количество еды.
Но звучит очень интересно. С удовольствием поигрался бы.
Я же не ставил целью имитацию эволюции. Я сделал набор искусственных правил, органичивающих живность, и наблюдаю как она подстраивается.
Очень интересно смотреть как реагируют стада на резкое сокращение количества травы.
Или как отдельные особи начинают резко плодиться, когда появляется большое количество еды.
Но звучит очень интересно. С удовольствием поигрался бы.
Вот архив.
В нем два бинарника на 16 и 128 «особей».
От себя добавлю, зум колесиком, но его поведение не совсем как в играх и к сожалению пока не хватает удобного способа перемещения в плоскости, кроме как уменьшил/увеличил. Выбор юнитов левой кнопкой, а правой отправка в пункт назначения.
В нем два бинарника на 16 и 128 «особей».
«Результаты вообще» публиковать еще рано. Не во что пока поиграть.
Есть только части, которые я в основном по отдельности тестирую.
Из того, что можно показать — вот, например, полугодовой давности
сборка с лабиринтом. Можете погонять живность, если интересно.
От себя добавлю, зум колесиком, но его поведение не совсем как в играх и к сожалению пока не хватает удобного способа перемещения в плоскости, кроме как уменьшил/увеличил. Выбор юнитов левой кнопкой, а правой отправка в пункт назначения.
Думаю, всем будет интересно, если ваш товарищ напишет статью о том, с какими подводными камнями сталкивался при разработке.
Да и инвайт за это, думаю. без особых проблем получит.
Да и инвайт за это, думаю. без особых проблем получит.
Я думаю он пока в этом не сильно заинтересован, да и как я он сам написал
«Результаты вообще» публиковать еще рано. Не во что пока поиграть.
Большую статью про разработку я сейчас точно писать не буду. Хотя бы потому, что эта разработка не дошла хотя бы до альфа-версии.
И с камнями я сталкиваюсь до сих пор и постоянно. (Главный — «памяти мне дайте, памяти, да побольше»! 2ГБ на процесс катастрофически мало. Но может в рабочей версии на динамически изменяемое поле хотя бы в несколько «квадратных километров» и на полсотни особей этой памяти хватит...)
Думаю, можно будет написать статью тогда, когда тестовая версия будет доступна для скачивания — тогда материала будет побольше и он будет более предметным.
Продолжение: Evo, часть 2 — о скрещивании
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Аналог игры «Жизнь» — Evo