paleoforum.ru

Цитата: PVOzerski от октября 30, 2010, 21:50:55
Вопрос: "задавать параметры массивов "на лету"" - что имеется в виду?

Чтобы было удобно задавать многомерные массивы переменной длины, и чтобы это можно было делать в процессе выполнения программы, когда значение переменных заранее не известно, а задается в зависимости от результатов вычислений других модулей программы.
Описанное здесь:
http://www.paleo.ru/forum/index.php/topic,3339.msg78170.html#msg78170
можно использовать повсеместно, как универсальный алгоритм принятия решений. А поскольку ситуации бывают разные, то и ни один из параметров нельзя задавать жестко.

Переменная длина массивов в том диалекте паскаля, который реализован в Delphi и FreePascal, задается легко. Вот с количеством измерений у массивов там плохо: задаются жестко - хотя можно организовать, например, сложные списки через указатели.

Цитата: PVOzerski от октября 30, 2010, 22:32:19
Переменная длина массивов в том диалекте паскаля, который реализован в Delphi и FreePascal, задается легко. Вот с количеством измерений у массивов там плохо: задаются жестко - хотя можно организовать, например, сложные списки через указатели.

Запасные измерения, раз уже на то пошло, можно положить одноэлементыми. Это не проблема.

Согласен. Так что можно обойтись без Ruby

Цитата: Bertran от октября 30, 2010, 23:01:26Запасные измерения, раз уже на то пошло, можно положить одноэлементыми. Это не проблема.

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

Единицу можно будет потом менять. Лично я пока не знаю как. И лично мне не видно необходимости что-то строить настолько глобальное, чтобы не обращаться при моделировании к самой среде программирования. Все значения, в конце концов, можно подставлять и среде.

В этом смысле матлаб 2007 наиболее оптимален: там мы не программируем (т.е., не заморачиваемся по многим вещам), мы решаем задачу.

Цитата: PVOzerski от октября 30, 2010, 23:22:41Согласен. Так что можно обойтись без Ruby

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

Цитата: vitus от октября 31, 2010, 20:07:52
Если BolandPascal совместим с Free, тогда я могу написать кусок кода, отвечающий за эволюцию наших амеб, а Вы напишите обсуждаемый выше модуль, идет?

Это не ко мне Вы обращаетесь, верно?

Цитата: Bertran от октября 31, 2010, 20:09:39
Это не ко мне Вы обращаетесь, верно?

Верно

Цитата: Bertran от октября 31, 2010, 20:07:35
В этом смысле матлаб 2007 наиболее оптимален: там мы не программируем (т.е., не заморачиваемся по многим вещам), мы решаем задачу.

К матлабу можно прикручивать финтифлюшки, написанные на С. Могу написать "эволюционный модуль" на С, а с Вас тогда исполняемый и "прикрутить финтифлюшку", идет?
На счет среды.
Мы имеем пищу и температуру.
Температуру вводим как коэффициент, накладывающийся на все формулы, связанные с длительностью любых циклов.
Под "пищей" давайте понимать пакеты символов из которых наша модель сможет строить собственные копии (т.е. написать код своих копий она сможет только при наличии достаточного количества символов, имеющихся у нее в распоряжении).
Предположим, что в начале пища есть в каждой точке пространства. Состав пищи пока положим случайным (хотя с пищей тоже можно ого-го чего закрутить!). Количество пищи в каждой точке возрастает со временем, чем больше температура в этой точке, тем быстрее возрастает количество. Если в результате действий нашей модели количество пищи в точке сократилось до нуля, то в этой точке прирост пищи прекращается до тех пор, пока в одной из соседних точек количество пищи не возрастет до какого-то уровня.
Внутренние запасы пищи нашей модели уменьшаются с течением времени, расходуются на движение и размножение, рост температуры ускоряет расходование пищи...

Т.е. наша амеба будет есть, размножаться и иногда нагреваться. Через N поколений смотрим как изменился "угол наклона оси" для большинства особей популяции и подсчитываем количество маргиналов, ага?

Цитата: vitus от октября 31, 2010, 20:11:43
К матлабу можно прикручивать финтифлюшки, написанные на С. Могу написать "эволюционный модуль" на С, а с Вас тогда исполняемый и "прикрутить финтифлюшку", идет?

Прикручивать я не умею, если я Вас правильно понял. Ну а начать я пока не могу, возможно, потом. Это же кучу времени нужно угробить.

Цитата: Bertran от октября 31, 2010, 21:02:44

Цитата: vitus от октября 31, 2010, 20:11:43
К матлабу можно прикручивать финтифлюшки, написанные на С. Могу написать "эволюционный модуль" на С, а с Вас тогда исполняемый и "прикрутить финтифлюшку", идет?

Прикручивать я не умею, если я Вас правильно понял. Ну а начать я пока не могу, возможно, потом. Это же кучу времени нужно угробить.

Вот потому-то я и настаиваю на том, чтобы во-первых, сначала основательно продумать общую схему модели, а во-вторых, чтобы эволюция нашей модели шла путем уточнений: сначала модули описываются "в общих чертах", а потом каждый желающий вносит в них уточнения. Например, не нравится кому-то, что модель начинает создавать собственную копию сразу же по достижению необходимого запаса пищи - прикручивает вариабельность этого параметра, не нравится, что солнечный свет кастрирован до температуры - прикручивает задел для возникновения автотрофного питания и т.п. ...
Это необходимо для того, чтобы можно было запустить модель в свободное плавание в интернеты, чтобы потом она вернулась, обросшая уточнениями - т.к. у многих, особенно молодых, людей существует занятнейшая проблема - придумать как убить время.

Цитата: vitus от октября 31, 2010, 21:08:35
(...)запустить модель в свободное плавание в интернеты
(...)у многих, особенно молодых, людей существует занятнейшая проблема - придумать как убить время.

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

Цитата: Bertran от октября 31, 2010, 21:26:21
Данная затея - мощнейший удар по "адекватности" модели, которую, я так полагаю, мы стремимся получить. Можно получить море мусора, из которого трудно будет извлечь что-либо полезное. Поэтому, предлагаю оставить решать проблемы "молодых людей" им самим.

Как минимум, так мы можем решить проблему создания разнообразного меню для нашей "адекватной" амебы, когда научим ее охотиться )))
Вы все время пытаетесь опуститься на уровень организмов. Зачем? Давайте работать с видом.
Прошу прощения, пора бежать на работу.

Цитата: Bertran от октября 31, 2010, 21:26:21
Можно получить море мусора, из которого трудно будет извлечь что-либо полезное.

"техники, конечно, не понимаю, но "мусор" - это как раз то, что цепляет на себя клетка, но каким-то образом отсеивает и сортирует его. При делении? А нельзя ли сделать, что бы, допустим, в новую клетку допусался десятикратно повторенный мусор, а в старую, скажем, дважды. Какая будет более выживаема?

Цитата: василий андреевич от ноября 01, 2010, 17:46:55
"техники, конечно, не понимаю, но "мусор" - это как раз то, что цепляет на себя клетка, но каким-то образом отсеивает и сортирует его.

Я не о том "мусоре". Я говорил о возможных доработках программы другими пользователями, если оставить её код открытым и предоставить возможность его изменять любому желающему. Изменения, мягко говоря, могут не совсем соответствовать нашим планам.