paleoforum.ru

Цитата: василий андреевич от октября 28, 2010, 11:53:25
"доза"- плохой термин. В общем случае он означает количество пряников поощрения.

Я варьировать дозы не собираюсь. Пускай этим естественный отбор занимается.

Цитата: vitus от октября 27, 2010, 01:15:23
У нашей амебы есть инструкции, которые могут входить в противоречие (убегай от освещения, но стремись к пище).

Чтобы не возиться с "диалектическими противоречиями", предлагаю обратиться к областям D_i, о которых было выше.

То же самое касается "старика Зенона". К противоречиям он приходил не от того, что не принимал время и (или) расстояние дискретными (это, впрочем, и поныне не столь ясный вопрос), а от того, что не умел суммировать ряды (геометрическую прогрессию со знаменателем, меньшим по модулю единицы).

Вам такое "противоречие" любой школьник в 9 классе успешно разрешит.

Я не объяснял, как введение областей D_i снимает "противоречия". Объяснить, или это очевидно и в объяснении не нуждается?

Цитата: Bertran от октября 29, 2010, 00:57:21
Я не объяснял, как введение областей D_i снимает "противоречия". Объяснить, или это очевидно и в объяснении не нуждается?

Наверно, стоит объяснить.

Цитата: vitus от октября 29, 2010, 10:27:35
Наверно, стоит объяснить.

Было бы гораздо лучше, если бы под рукой была доска и мел. Поскольку их нет, то рисунки будем воображать.

Предположим, что амёба может реагировать на 2 параметра (если их больше, то выберем из них 2). Пусть это будет, например, градиент температуры и параметр "желанности пищи" (этим параметром для простоты будем считать массу пищи). Также предположим одномерность пространства: амёба может двигаться вперёд либо назад (многомерный случай качественно картину не меняет, но требует более громоздких выкладок). Массу m будем мерить в некоторых единицах массы (например, граммы, милиграммы и т.п.), градиент температуры (обозначим dT/dx) - в некоторых единицах градиента температуры (например, K/м (градус Кельвина на метр), К/мм и т.п.). Будем считать, что еда находится справа от амёбы. Тогда, чтобы приблизиться к еде, необходимо увеличивать линейную координату.

Будем полагать, что ответ амёбы может быть лишь одним из двух: перемещение к еде (вправо, S_1), либо перемещение от еды (влево, S_2). Зададим области D_1, D_2. Построим для этого двумерную декартовую систему координат. Горизонтальной оси будет соответствовать параметр dT/dx, а вертикальной - m>0. Тогда возможными будут лишь конфигурации верхней полуплоскости декартовой плоскости. От нуля в первую четверть проведём некоторую прямую. Область, образовавшуюся под прямой, обозначим D_2, а всю остальную область - D_1.

Пусть при движении к еде температура возрастает, т.е. dT/dx>0. Тогда перед амёбой, как ранее мы бы полагали, противоречие: с одной стороны, она стремится вправо, поскольку там еда, а с другой - влево, поскольку вправо возрастает температура. По новой же (грубой и иллюстративной, что касается числовых значений) модели амёба будет двигаться вправо, если совокупность (точнее, вектор) параметров (dT/dx, m) принадлежит D_1, и влево - если (dT/dx, m) принадлежит D_2. В нашем случае, принимая в расчёт способ построения областей, амёба будет двигаться к еде, если отношение массы еды к градиенту температуры больше некоторого заданного значения (оно равно тангенсу угла наклона прямой к горизонтальной оси), и от еды - если меньше. Таким образом, для всех возможных параметров (dT/dx, m) действия амёбы S_i чётко определены.

Остается только добавить следствия принятия решений S_1, S_2 и возможность менять случайным образом угол наклона прямой в поколениях (?) и этот поведенческий срез можно считать завершенным.

Цитата: vitus от октября 29, 2010, 17:16:10
Остается только добавить следствия принятия решений S_1, S_2 и возможность менять случайным образом угол наклона прямой в поколениях (?) и этот поведенческий срез можно считать завершенным.

В общем, да.

Цитата: Bertran от октября 29, 2010, 18:05:02
В общем, да.

Хорошо. Давайте подождем пока кто-нибудь из людей, разбирающихся в том, как превращать математику в программный код, поможет нам определиться с выбором языка программирования и можно будет начинать воплощать сие в коде.

Тут математики почти нет. Всё изложенное накодировать даже я смогу. Просто пока занят немного. В моих силах написать код в среде Delphi 7, либо MatLab 2007.

Замечу, что программная разработка сего элементарного примера, кажется, не особо нужна, поскольку здесь и так всё ясно.

Цитата: Bertran от октября 29, 2010, 21:34:48
Тут математики почти нет. Всё изложенное накодировать даже я смогу. Просто пока занят немного. В моих силах написать код в среде Delphi 7, либо MatLab 2007.
Замечу, что программная разработка сего элементарного примера, кажется, не особо нужна, поскольку здесь и так всё ясно.

А Вы умеете Delphi и Ruby состыковывать?

Цитата: vitus от октября 30, 2010, 13:07:48
А Вы умеете Delphi и Ruby состыковывать?

Честно говоря, впервые слышу о таком языке.

Цитата: Bertran от октября 30, 2010, 13:29:03
Честно говоря, впервые слышу о таком языке.

Лучше бы сразу определиться с языком, чтобы потом по 100 раз не переписывать. Я за Ruby потому что кроме метапрограммирования он позволяет задавать параметры массивов "на лету", что нам очень пригодится в будущем.

Delphi и вообще Паскаль как "однопроходной" компилятор (утконосы с ехиднами тут не при чем ) очень быстро транслирует. А поскольку генерится нативный машинный код, то программа будет считать быстро. Ruby же - интерпретатор, что автоматически означает медленную работу программы, на нем написанной. Единственное замечание по поводу Delphi - его недостаточная кросс-платформенность - по крайней мере, если задействовать VCL (что по умолчанию и происходит). Ну, а если на Delphi нет лицензии - то еще одно замечание Я бы, наверное, отталкиваясь от Delphi, предпочел связку FreePascal + Lazarus. А с динамическими массивами и вариантным типом и в Delphi, и во FreePascal всё не так уж плохо - а объектная ориентированность вообще "родная".

Цитата: vitus от октября 30, 2010, 19:26:57
Я за Ruby потому что кроме метапрограммирования он позволяет задавать параметры массивов "на лету", что нам очень пригодится в будущем.

Как пожелаете. Моё участие в программировании всё равно ожидается ограниченным, по крайней мере в ближайшей перспективе, поскольку у меня ограничены временные рамки. Пока вряд ли я смогу принять полномасштабное участие в программировании. Разве что в обсуждении.

Вопрос: "задавать параметры массивов "на лету"" - что имеется в виду?

Цитата: PVOzerski от октября 30, 2010, 20:01:01
Delphi и вообще Паскаль как "однопроходной" компилятор (утконосы с ехиднами тут не при чем ) очень быстро транслирует. А поскольку генерится нативный машинный код, то программа будет считать быстро.

Но эта особенность в то же время, накладывает ограничения на самомодификацию кода, если я не ошибаюсь. Компиляторам легче модифицировать сгенереный машинный код, верно?
А для создания эволюционирующих моделей, на мой взгляд, важно, чтобы предоставлялся как можно более полный функционал именно в области метапрограммирования. Мне кажется, это даже важнее чем скорость... Или нет?