Функциональное программирование и искусственная жизнь
З. З. Ы. А почему это я анонимусом отобразился? Это тоже связано с датой?Да. //Anonymous
функционального языка программирования, который бы позволял (достаточно легко) создавать потоки (многопоточность)... И чтобы потоки могли обмениваться друг с другом сообщениями?erlang
Как раз Форт для виртуальной машины гораздо больше подходит, чем функциональные языки. Как ты будешь в ФЯ контролировать CPU, ума не приложу. А в Форте - элементарно.
Дело всё в том, что форт императивен. А это означает, что любая мутация может запороть программу полностью. А в функциональном языке, насколько я понимаю, мутация скажется только на результате конкретной функции, и ежели он нигде не используется, то оная мутация не отразится на жизнедеятельности.
Ну и мои способности к программированию довольно скромны - написать-то я написал, вроде бы даже работает, но получилась та ещё кашица. Вот, в частности, я не пойму, почему не возникают мутации, заставляющие агентов посылать сообщения. Хотя вроде им ничто не мешает, и вероятность такой мутации довольно велика. Скорее всего, мешает как раз императивность.
А также я патологически не могу освоить сетевое программирование. Не знаю почему.
Ну и мои способности к программированию довольно скромны - написать-то я написал, вроде бы даже работает, но получилась та ещё кашица. Вот, в частности, я не пойму, почему не возникают мутации, заставляющие агентов посылать сообщения. Хотя вроде им ничто не мешает, и вероятность такой мутации довольно велика. Скорее всего, мешает как раз императивность.
А также я патологически не могу освоить сетевое программирование. Не знаю почему.
Как ты будешь в ФЯ контролировать CPU, ума не приложу.Я тоже.. А в каком смысле контролировать?
erlang - адекватный вариант.
Можно посмотреть в стороны лиспа. Он, кстати, очень близок по духу к Форту. И из него можно слепить все, что угодно, в том числе и многопоточность в стиле erlang. (уже сделано в библиотеке erlang-in-lisp)
Кстати, можно поподробнее об алгоритме и о том, как он реализован на форте?
Можно посмотреть в стороны лиспа. Он, кстати, очень близок по духу к Форту. И из него можно слепить все, что угодно, в том числе и многопоточность в стиле erlang. (уже сделано в библиотеке erlang-in-lisp)
Кстати, можно поподробнее об алгоритме и о том, как он реализован на форте?
а что такое мутация?
Кстати, можно поподробнее об алгоритме и о том, как он реализован на форте?
А что конкретно интересует? Грубо говоря, роль живых организмов играют программы на форте (т. н. агенты они могут размножаться, умирать, обмениваться сообщениями и т. п. А полное описание этого дела я до сих пор не сделал. Вот немного, скажем: http://forum.sources.ru/index.php?showtopic=119430 . И по первой ссылке некоторые идеи описаны.
А что делают эти организмы, какие функции выполняют, какими свойствами обладают.
Не смог этого найти на forum.sources, но мог плохо искать.
И все же, это самое важное, потому что на основе свойств организма оределяется его пригодность.
Возможно, при таком подходе (много независимых организмов) лучше юзать swarm-based алгоримы (муравьи, пчелы, particle swarm optimization которые не только близки по идее, но и ищут решения лучше ГА?
Не смог этого найти на forum.sources, но мог плохо искать.
И все же, это самое важное, потому что на основе свойств организма оределяется его пригодность.
Возможно, при таком подходе (много независимых организмов) лучше юзать swarm-based алгоримы (муравьи, пчелы, particle swarm optimization которые не только близки по идее, но и ищут решения лучше ГА?
А что делают эти организмы, какие функции выполняют, какими свойствами обладают.Ну скажем так, изначальная задумка была в том, чтобы можно было подсовывать агентам различные задачи, дабы они эволюционировали в разнообразной среде и было бы выгодно быть разнообразными/интеллектуальными. Ну, скажем, чтобы они играли друг с другом в матричные игры 2*2 или, например, в футбол. А также чтобы они могли общаться друг с другогм и сами вносить изменения в свой код - таким образом они могут изобрести некоторый аналог полового процесса, опять же для ускорения эволюции. Но на настоящий момент эта задумка упёрлась не знаю, во что больше - в технические или концептуальные трудности.
Такое описание устраивает? Можно более конкретные вопросы?
Вот тут ещё кое-что: http://erg.biophys.msu.ru/lamarckathome/forum/viewforum.php?... .
озможно, при таком подходе (много независимых организмов) лучше юзать swarm-based алгоримы (муравьи, пчелы, particle swarm optimizationЛучше для чего?
которые не только близки по идее, но и ищут решения лучше ГА?
Насколько мне объясняли, это немного другая степь. Что это суть технология для управления группами роботов. В принципе можно сказать, что у меня тоже нечто вроде этого - ибо агенты могут общаться и находятся в общей среде. Правда, они у меня не в евклидовом пространстве, а все сидят как бы в одной точке. Евклидово пространство мне когда-то показалось избыточным - скорее всего, напрасно. Хотя в принципе его не так уж сложно сделать.
Не согласен.
И ГА, и популяционные алгоритмы ищут оптимальное решение функции пригодности. На те и на другие можно наложить ограничения, защищающие популяцию от вырождения.
И вообще, оригинальный подход к генетическому программированию описан в книге John Koza "Genetic programming" - применение генетических алгоритмов к исходному коду программ.
По теме - с удовольствием присоединился бы к написанию этой штуковины, но после сессии.
И ГА, и популяционные алгоритмы ищут оптимальное решение функции пригодности. На те и на другие можно наложить ограничения, защищающие популяцию от вырождения.
И вообще, оригинальный подход к генетическому программированию описан в книге John Koza "Genetic programming" - применение генетических алгоритмов к исходному коду программ.
По теме - с удовольствием присоединился бы к написанию этой штуковины, но после сессии.
И ГА, и популяционные алгоритмы ищут оптимальное решение функции пригодности. На те и на другие можно наложить ограничения, защищающие популяцию от вырождения.
А можно поподробнее? Честно говоря, не слышал названия "популяционные алгоритмы" в контексте решения задач оптимизации. Что под этим понимается?
И вообще, оригинальный подход к генетическому программированию описан в книге John Koza "Genetic programming" - применение генетических алгоритмов к исходному коду программ.
Лежит у меня, насколько я помню, оная книжка на винчестере, всё никак не соберусь прочитать..
По теме - с удовольствием присоединился бы к написанию этой штуковины, но после сессии.С удовольствием бы принял помощь, особенно от компетентного человека. Пиши в аську 373753963, джаббер qip.ru, livejournal.com.
зачем писать? все уже написано. ищи в инете, читай джона кОзу, прогается элементарно на том же шарпе или дельфи.
к слову, я когда-то, фанатея от ГП, написал на нем эволюционирующий алгоритм игры ИИ в гаму типа варкрафта. и действительно эволюционировало
к слову, я когда-то, фанатея от ГП, написал на нем эволюционирующий алгоритм игры ИИ в гаму типа варкрафта. и действительно эволюционировало
зачем писать? все уже написано.
Неправда! Самого-то главного нет - искусственного интеллекта, сопоставимого с человеческим.
к слову, я когда-то, фанатея от ГП, написал на нем эволюционирующий алгоритм игры ИИ в гаму типа варкрафта. и действительно эволюционировало
Можно посмотреть?
И вот наконец не оффтопик!
Во-первых, ни один из существующих функциональных языков тебе не подойдёт, они все слишком сложные. Сложные в том смысле что во-первых ты задолбаешься писать генератор, во-вторых, он будет неэффективен (потому что будет тратить силы на попытки использовать сравнительно бесполезные фичи языка в третьих, ты нифига не поймёшь в его выводе (впрочем, это к любым эволюционирующим программам относится в четвёртых, задача реалистичного ограничения процессорной мощности будет весьма сложна. То есть можно, конечно, взять f#, который компилится в обычные дотнетовские ассембли, написать подпатчивалку, которая тупо будет считать количество MSIL инструкций в каждой процедуре и вставлять записывание посчитанного в глобальную переменную перед возвратом, но это как-то некрасиво и сложно.
Настоятельно рекомендую ознакомиться с http://en.wikipedia.org/wiki/Combinatory_logic, после чего поискать гуглом 'Combinatory logic SKI evolution' или что-то в таком духе, я видел когда-то статью про это. И про лямбда-исчисление в википедии же почитай. Как бы тебе надо работать с основами, а не с real-life имплементациями.
Ах, ну и само собой всё это ты должен реализовать в виде интерпретатора, который считает свои шаги. Вряд ли стремление к повышению производительности заставит тебя опять же компилить свою фигню в MSIL или другой какой байткод, вставляя туда вызовы метода родителя с количеством исполненных инструкций.
Во-первых, ни один из существующих функциональных языков тебе не подойдёт, они все слишком сложные. Сложные в том смысле что во-первых ты задолбаешься писать генератор, во-вторых, он будет неэффективен (потому что будет тратить силы на попытки использовать сравнительно бесполезные фичи языка в третьих, ты нифига не поймёшь в его выводе (впрочем, это к любым эволюционирующим программам относится в четвёртых, задача реалистичного ограничения процессорной мощности будет весьма сложна. То есть можно, конечно, взять f#, который компилится в обычные дотнетовские ассембли, написать подпатчивалку, которая тупо будет считать количество MSIL инструкций в каждой процедуре и вставлять записывание посчитанного в глобальную переменную перед возвратом, но это как-то некрасиво и сложно.
Настоятельно рекомендую ознакомиться с http://en.wikipedia.org/wiki/Combinatory_logic, после чего поискать гуглом 'Combinatory logic SKI evolution' или что-то в таком духе, я видел когда-то статью про это. И про лямбда-исчисление в википедии же почитай. Как бы тебе надо работать с основами, а не с real-life имплементациями.
Ах, ну и само собой всё это ты должен реализовать в виде интерпретатора, который считает свои шаги. Вряд ли стремление к повышению производительности заставит тебя опять же компилить свою фигню в MSIL или другой какой байткод, вставляя туда вызовы метода родителя с количеством исполненных инструкций.
Вряд ли стремление к повышению производительности заставит тебя опять же компилить свою фигню в MSIL или другой какой байткод, вставляя туда вызовы метода родителя с количеством исполненных инструкций.Да я думаю за полчаса можно написать программу, которая будет автоматически патчить байткод для подсчёта инструкций.
Один компьютер может симулировать не одну тысячу нейронов, а в коре головного мозга их всего 10-20 миллиардов. 10-20 миллионов компьютеров должно хватить.Одна только незадача - компьютерные нейроны и нейроны в человеческом мозгу - это небо и земля. Не в смысле вычислительной мощности, а в смысле выдаваемого результата.
Сложные в том смысле что во-первых ты задолбаешься писать генератор,
Генератор чего? И почему задолбаюсь?
во-вторых, он будет неэффективен (потому что будет тратить силы на попытки использовать сравнительно бесполезные фичи языка)
Я читал, что есть реализации лиспа, не уступающие в эффективности С++.. Сам не измерял, к сожалению.
в третьих, ты нифига не поймёшь в его выводе (впрочем, это к любым эволюционирующим программам относится)
Я это у себя уже наблюдаю. Впрочем, это уже относится к недостаткам проектирования, а не языка. Чисто теоретически с ФЯ должно быть в этом смысле проще - в силу той же инкапсуляции.
в четвёртых, задача реалистичного ограничения процессорной мощности будет весьма сложна. То есть можно, конечно, взять f#, который компилится в обычные дотнетовские ассембли, написать подпатчивалку, которая тупо будет считать количество MSIL инструкций в каждой процедуре и вставлять записывание посчитанного в глобальную переменную перед возвратом, но это как-то некрасиво и сложно.
Я поступил куда банальнее - просто оформил каждого агента в отдельный виндовый поток. Можно ещё изобрести свой диспетчер потоков, но я этим ещё не занимался. Я всегда думал, что в ФЯ тоже должны быть подобные средства - ведь они позиционируются как легко (вплоть до автоматически) поддающиеся распараллеливанию.
Настоятельно рекомендую ознакомиться с
Ознакомлюсь на досуге..
Как бы тебе надо работать с основами, а не с real-life имплементациями.
В каком смысле?
No, there is no a silver bullet out there.
во-первых ты задолбаешься писать генератор
Кажется, я понял, что имеется в виду. Генератор правильно записанных программ. Здесь я склонен идти другим путём - не генерировать программы определённого вида, а так доработать интерпретатор исходного текста (грубо говоря, поставить "препроцессор" чтобы любая последовательность символов воспринималась как правильная программа. Особенно это важно в связи с тем, что одна из основных моих идей заключается в возможности агента изменять собственный исходный код. В форте это элементарно - попросту надо игнорировать незнакомые слова. В лиспе, насколько я понял, то же самое плюс надо добавлять скобки по необходимости. Как насчёт эрланга - не знаю, я ещё вовсе не открывал никаких пособий по эрлангу.
Настоятельно рекомендую ознакомиться с http://en.wikipedia.org/wiki/Combinatory_logic
Много буков.. Нет ли чего-либо "для чайников"?
после чего поискать гуглом 'Combinatory logic SKI evolution'
Поискал, что-то он мне выдал, но я не уверен, что это то, что надо. Можно поконкретнее?
> Дело всё в том, что форт императивен. А это означает, что
> любая мутация может запороть программу полностью.
Наглая ложь.
> А в функциональном языке, насколько я понимаю, мутация
> скажется только на результате конкретной функции, и ежели он
> нигде не используется, то оная мутация не отразится на
> жизнедеятельности.
Наглая ложь.
> Вот, в частности, я не пойму, почему не возникают мутации,
> заставляющие агентов посылать сообщения. Хотя вроде им ничто
> не мешает, и вероятность такой мутации довольно велика. Скорее
> всего, мешает как раз императивность.
Non sequitur.
---
"Narrowness of experience leads to narrowness of imagination."
> любая мутация может запороть программу полностью.
Наглая ложь.
> А в функциональном языке, насколько я понимаю, мутация
> скажется только на результате конкретной функции, и ежели он
> нигде не используется, то оная мутация не отразится на
> жизнедеятельности.
Наглая ложь.
> Вот, в частности, я не пойму, почему не возникают мутации,
> заставляющие агентов посылать сообщения. Хотя вроде им ничто
> не мешает, и вероятность такой мутации довольно велика. Скорее
> всего, мешает как раз императивность.
Non sequitur.
---
"Narrowness of experience leads to narrowness of imagination."
> Я всегда думал, что в ФЯ тоже должны быть подобные средства -
> ведь они позиционируются как легко (вплоть до автоматически)
> поддающиеся распараллеливанию.
Параллельность --- это отдельная тема, сложная и интересная.
Всё не так просто. На твоей задаче распараллеливание может как быть,
так и не быть. Вообще, независимо от языка программирования.
К твоему сведению, даже Язык Программирования (настоящий, а не
все эти ваши игрушки) поддаётся автоматическому распараллеливанию.
---
...Я работаю антинаучным аферистом...
> ведь они позиционируются как легко (вплоть до автоматически)
> поддающиеся распараллеливанию.
Параллельность --- это отдельная тема, сложная и интересная.
Всё не так просто. На твоей задаче распараллеливание может как быть,
так и не быть. Вообще, независимо от языка программирования.
К твоему сведению, даже Язык Программирования (настоящий, а не
все эти ваши игрушки) поддаётся автоматическому распараллеливанию.
---
...Я работаю антинаучным аферистом...
> Дело всё в том, что форт императивен. А это означает, что
> любая мутация может запороть программу полностью.
Наглая ложь.
Ты на форте когда последний раз программировал? Ты хочешь сказать, что форт не императивен? Ты бы лучше сидел и в контру играл, а не постулировал необоснованные утверждения.
> А в функциональном языке, насколько я понимаю, мутация
> скажется только на результате конкретной функции, и ежели он
> нигде не используется, то оная мутация не отразится на
> жизнедеятельности.
Наглая ложь.
Обоснуй..
Требования малопонятны, так что "достаточно легко" не получится. Поясни.
А что непонятного-то? Есть некоторые виртуальные организмы, они представляют собой программы, выполняющиеся каждая в своём потоке. Стало быть, они должны как-то общаться со средой и друг с другом.
Что значит "была бы весьма кстати"? Чем не устроили возможности Форта?Инкапсуляция инкапсуляции рознь. Одно дело - когда мы определяем высокоуровневые слова, которые делают то же самое, что и некоторая последовательность низкоуровневых. Это тоже можно назвать инкапсуляцией, но я говорю про другое - когда мы запрещаем функции изменять другие места программы, помимо её собственного результата. Вот этого в форте нет. Наверное, это как-то можно реализовать, но то, что получится, уже не будет по своей сути фортом.
Возможности инкапсуляции там достаточны. Хоть всё запрячь.
Где ссылка на код, чтобы можно было посмотреть, что ты наваял?
Так в первом же сообщении ссылка. Ежели точнее, то http://erg.biophys.msu.ru/lamarckathome/forum/viewtopic.php?...
>>> Дело всё в том, что форт императивен. А это означает, что
>>> любая мутация может запороть программу полностью.
>> Наглая ложь.
> Ты на форте когда последний раз программировал?
Сегодня.
> Ты хочешь сказать, что форт не императивен?
Нет. Я утверждаю, что всё утверждение ложно, потому что из истинного
"форт императивен" выводится ложное "любая мутация может."
> Ты бы лучше сидел и в контру играл, а не постулировал
> необоснованные утверждения.
>>> А в функциональном языке, насколько я понимаю, мутация
>>> скажется только на результате конкретной функции, и ежели он
>>> нигде не используется, то оная мутация не отразится на
>>> жизнедеятельности.
>> Наглая ложь.
> Обоснуй..
Только в особых случаях, когда результат подвыражение отбрасывается,
мутация не сказывается на всём выражении. Поэтому твоё утверждение
имеет очень ограниченную область применения в функциональных языках
как композиционных, так и комбинаторных (включая основанные на
лямбда-исчислении). Уже нет смысла говорить про возникающие
из-за неверного числа аргументов ошибки _времени исполнения_,
если ты используешь языки семейства лисп, и про непонятки с
типами, если ты используешь языки семейства ML и аналогичные.
---
"Narrowness of experience leads to narrowness of imagination."
>>> любая мутация может запороть программу полностью.
>> Наглая ложь.
> Ты на форте когда последний раз программировал?
Сегодня.
> Ты хочешь сказать, что форт не императивен?
Нет. Я утверждаю, что всё утверждение ложно, потому что из истинного
"форт императивен" выводится ложное "любая мутация может."
> Ты бы лучше сидел и в контру играл, а не постулировал
> необоснованные утверждения.
>>> А в функциональном языке, насколько я понимаю, мутация
>>> скажется только на результате конкретной функции, и ежели он
>>> нигде не используется, то оная мутация не отразится на
>>> жизнедеятельности.
>> Наглая ложь.
> Обоснуй..
Только в особых случаях, когда результат подвыражение отбрасывается,
мутация не сказывается на всём выражении. Поэтому твоё утверждение
имеет очень ограниченную область применения в функциональных языках
как композиционных, так и комбинаторных (включая основанные на
лямбда-исчислении). Уже нет смысла говорить про возникающие
из-за неверного числа аргументов ошибки _времени исполнения_,
если ты используешь языки семейства лисп, и про непонятки с
типами, если ты используешь языки семейства ML и аналогичные.
---
"Narrowness of experience leads to narrowness of imagination."
>> Требования малопонятны, так что "достаточно легко" не получится. Поясни.
> А что непонятного-то? Есть некоторые виртуальные организмы,
> они представляют собой программы, выполняющиеся каждая в своём
> потоке. Стало быть, они должны как-то общаться со средой и
> друг с другом.
На функциональных языках это будет сложнее сделать, чем на форте.
>> Что значит "была бы весьма кстати"? Чем не устроили возможности Форта?
>> Возможности инкапсуляции там достаточны. Хоть всё запрячь.
> Инкапсуляция инкапсуляции рознь. Одно дело - когда мы
> определяем высокоуровневые слова, которые делают то же самое,
> что и некоторая последовательность низкоуровневых. Это тоже
> можно назвать инкапсуляцией, но я говорю про другое - когда мы
> запрещаем функции изменять другие места программы, помимо её
> собственного результата. Вот этого в форте нет.
Наглая ложь. Тебе ничто не мешает переопределить все мешающие
слова и убрать их из словаря.
> Наверное, это как-то можно реализовать, но то, что получится,
> уже не будет по своей сути фортом.
Кто это сказал? Приведёшь ссылку?
>> Где ссылка на код, чтобы можно было посмотреть, что ты наваял?
> Так в первом же сообщении ссылка.
Судя по содержимому, ты наваял очень нестандартный форт в стиле
чайлдеровского "Ретро".
В целом, код скучный, очень много повторов, что совсем не в духе
"цветных", итераторы сделаны дубово. Моё мнение: нисколько не
удивительно, что у тебя ничего не получилось. Ты выбрал совсем
не то направление внутри форта, тебе надо было брать: а) готовую
систему, чтобы освободить время для _своей_ задачи; б) стандартную
систему (или близкую к таковой чтобы у тебя были полновесные
традиционные словари и многое другое.
Да, "later", конечно, занятная конструкция, но использовать её
особого смысла не имеет, она неудобна.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> А что непонятного-то? Есть некоторые виртуальные организмы,
> они представляют собой программы, выполняющиеся каждая в своём
> потоке. Стало быть, они должны как-то общаться со средой и
> друг с другом.
На функциональных языках это будет сложнее сделать, чем на форте.
>> Что значит "была бы весьма кстати"? Чем не устроили возможности Форта?
>> Возможности инкапсуляции там достаточны. Хоть всё запрячь.
> Инкапсуляция инкапсуляции рознь. Одно дело - когда мы
> определяем высокоуровневые слова, которые делают то же самое,
> что и некоторая последовательность низкоуровневых. Это тоже
> можно назвать инкапсуляцией, но я говорю про другое - когда мы
> запрещаем функции изменять другие места программы, помимо её
> собственного результата. Вот этого в форте нет.
Наглая ложь. Тебе ничто не мешает переопределить все мешающие
слова и убрать их из словаря.
> Наверное, это как-то можно реализовать, но то, что получится,
> уже не будет по своей сути фортом.
Кто это сказал? Приведёшь ссылку?
>> Где ссылка на код, чтобы можно было посмотреть, что ты наваял?
> Так в первом же сообщении ссылка.
Судя по содержимому, ты наваял очень нестандартный форт в стиле
чайлдеровского "Ретро".
В целом, код скучный, очень много повторов, что совсем не в духе
"цветных", итераторы сделаны дубово. Моё мнение: нисколько не
удивительно, что у тебя ничего не получилось. Ты выбрал совсем
не то направление внутри форта, тебе надо было брать: а) готовую
систему, чтобы освободить время для _своей_ задачи; б) стандартную
систему (или близкую к таковой чтобы у тебя были полновесные
традиционные словари и многое другое.
Да, "later", конечно, занятная конструкция, но использовать её
особого смысла не имеет, она неудобна.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Какой ты милый :3
Но всё-таки нафига ты советуешь человеку использовать форт в его задаче? Я ж писал уже - ни один general purpose language не подойдёт как он есть, разве что использовать его в качестве таргет вм - ограничивая себя неким дико узким сабклассом инструкций. И переживая по поводу того, что обычно языки возлагают ответственность за своевременный отлов бесконечных циклов и прочих делений на ноль на плечи кодера, а в нашем случае он как бы отсутствует и нужно делать его симулякр.
Алсо, я действительно проимел и никак не найду ту статью, где исследуется пригодность SKI для генетических алгоритмов, порождающих алгоритмы (и нафиг лямбды, не нужны же, прекрати лиспоёбствовать). Ты, видимо, СОВЕРШЕННО не понимаешь их сути и requirements. Что какая-то мутация может убить всё - это всегда так и никого не волнует. Важно чтобы обычно были мутации улучшающие результат сами по себе - и форт тут сосёт: если тебе нужно в одном месте положить на стек число, а в другом - взять, то это две мутации, а ведь так у вас всё. Нельзя так делать.
Конечно, иногда случаются локальные максимумы, где никак нельзя одной мутацией что-то улучшить, для борьбы с ними нужна junk DNA как пул рандомных данных, типа набор желательно не совсем случайных, а оставшихся от предыдущих попыток и достаточно обезображенных неиспользуемых функций, подключение которых таки является одной инструкцией.
Но всё-таки нафига ты советуешь человеку использовать форт в его задаче? Я ж писал уже - ни один general purpose language не подойдёт как он есть, разве что использовать его в качестве таргет вм - ограничивая себя неким дико узким сабклассом инструкций. И переживая по поводу того, что обычно языки возлагают ответственность за своевременный отлов бесконечных циклов и прочих делений на ноль на плечи кодера, а в нашем случае он как бы отсутствует и нужно делать его симулякр.
Алсо, я действительно проимел и никак не найду ту статью, где исследуется пригодность SKI для генетических алгоритмов, порождающих алгоритмы (и нафиг лямбды, не нужны же, прекрати лиспоёбствовать). Ты, видимо, СОВЕРШЕННО не понимаешь их сути и requirements. Что какая-то мутация может убить всё - это всегда так и никого не волнует. Важно чтобы обычно были мутации улучшающие результат сами по себе - и форт тут сосёт: если тебе нужно в одном месте положить на стек число, а в другом - взять, то это две мутации, а ведь так у вас всё. Нельзя так делать.
Конечно, иногда случаются локальные максимумы, где никак нельзя одной мутацией что-то улучшить, для борьбы с ними нужна junk DNA как пул рандомных данных, типа набор желательно не совсем случайных, а оставшихся от предыдущих попыток и достаточно обезображенных неиспользуемых функций, подключение которых таки является одной инструкцией.
> Но всё-таки нафига ты советуешь человеку использовать форт в его задаче?
Я не советую, я просто указываю на такую возможность.
> Я ж писал уже - ни один general purpose language не подойдёт
> как он есть, разве что использовать его в качестве таргет вм -
> ограничивая себя неким дико узким сабклассом инструкций.
Если брать форт, его можно использовать "хостед", то есть так,
как оно всё задумывалось изначально.
> И переживая по поводу того, что обычно языки возлагают
> ответственность за своевременный отлов бесконечных циклов и
> прочих делений на ноль на плечи кодера, а в нашем случае он
> как бы отсутствует и нужно делать его симулякр.
Как бы, отлавливать бесконечные циклы и деления на нуль на форте
не просто, а очень просто. По крайней мере, я не вижу в этом
трудности.
> Важно чтобы обычно были мутации улучшающие результат сами по
> себе - и форт тут сосёт: если тебе нужно в одном месте
> положить на стек число, а в другом - взять, то это две
> мутации, а ведь так у вас всё. Нельзя так делать.
Да какая разница? Ты прицепился к стеку, как будто ты
собираешься отдавать агентам слова из CORE. Ежу понятно,
что не надо так делать. Это следует из предметной области.
(Кстати, расскажи, чем так принципиально отличаются комбинаторы
от лямбда-выражений. Я хочу послушать.)
> Конечно, иногда случаются локальные максимумы, где никак
> нельзя одной мутацией что-то улучшить, для борьбы с ними нужна
> junk DNA как пул рандомных данных, типа набор желательно не
> совсем случайных, а оставшихся от предыдущих попыток и
> достаточно обезображенных неиспользуемых функций, подключение
> которых таки является одной инструкцией.
Я не думаю, что это хорошая модель эволюции.
Вообще, основная задача здесь --- построение правильной модели,
а не кодирование. При некотором желании, стековый автомат можно
и на лиспе сварганить.
---
...Я работаю антинаучным аферистом...
Я не советую, я просто указываю на такую возможность.
> Я ж писал уже - ни один general purpose language не подойдёт
> как он есть, разве что использовать его в качестве таргет вм -
> ограничивая себя неким дико узким сабклассом инструкций.
Если брать форт, его можно использовать "хостед", то есть так,
как оно всё задумывалось изначально.
> И переживая по поводу того, что обычно языки возлагают
> ответственность за своевременный отлов бесконечных циклов и
> прочих делений на ноль на плечи кодера, а в нашем случае он
> как бы отсутствует и нужно делать его симулякр.
Как бы, отлавливать бесконечные циклы и деления на нуль на форте
не просто, а очень просто. По крайней мере, я не вижу в этом
трудности.
> Важно чтобы обычно были мутации улучшающие результат сами по
> себе - и форт тут сосёт: если тебе нужно в одном месте
> положить на стек число, а в другом - взять, то это две
> мутации, а ведь так у вас всё. Нельзя так делать.
Да какая разница? Ты прицепился к стеку, как будто ты
собираешься отдавать агентам слова из CORE. Ежу понятно,
что не надо так делать. Это следует из предметной области.
(Кстати, расскажи, чем так принципиально отличаются комбинаторы
от лямбда-выражений. Я хочу послушать.)
> Конечно, иногда случаются локальные максимумы, где никак
> нельзя одной мутацией что-то улучшить, для борьбы с ними нужна
> junk DNA как пул рандомных данных, типа набор желательно не
> совсем случайных, а оставшихся от предыдущих попыток и
> достаточно обезображенных неиспользуемых функций, подключение
> которых таки является одной инструкцией.
Я не думаю, что это хорошая модель эволюции.
Вообще, основная задача здесь --- построение правильной модели,
а не кодирование. При некотором желании, стековый автомат можно
и на лиспе сварганить.
---
...Я работаю антинаучным аферистом...
Как бы, отлавливать бесконечные циклы и деления на нуль на фортеИ как? В смысле, бесконечные циклы как отлавливать? Подпатчить все слова, даваемые агентам, так, чтобы они проверяли счётчик и выпадали наружу, если он больше заданной величины? А в чём тогда вообще смысл использовать форт-то, если подобная виртуальная машина на нормальном языке пишется быстрее, выглядит проще, отлаживается легче, да и работает наверняка быстрее?
не просто, а очень просто. По крайней мере, я не вижу в этом
трудности.
Учти также, что если ты не хочешь использовать стековую модель (которая не подходит для этих целей из-за нелокальности, согласен? то тебе по-любому придётся писать свой интерпретатор — на нормальном языке это легче.
Более того, я хотел добавить, что единственным преимуществом форта является уже написанный лексер, но потом понял, что и это скорее недостаток: нам гораздо удобней генерить программы в уже распарсенном виде, и так же их интерпретировать.
(Кстати, расскажи, чем так принципиально отличаются комбинаторыУ лямбд есть именованные (или нумерованные) параметры. Это - нелокальность. Нелокальность - зло.
от лямбда-выражений. Я хочу послушать.)
>> Как бы, отлавливать бесконечные циклы и деления на нуль на форте
>> не просто, а очень просто. По крайней мере, я не вижу в этом
>> трудности.
> И как? В смысле, бесконечные циклы как отлавливать? Подпатчить
> все слова, даваемые агентам, так, чтобы они проверяли счётчик
> и выпадали наружу, если он больше заданной величины? А в чём
> тогда вообще смысл использовать форт-то, если подобная
> виртуальная машина на нормальном языке пишется быстрее,
> выглядит проще, отлаживается легче, да и работает наверняка
> быстрее?
Зачем "все"? Достаточно подпатчить "again", "until", "repeat",
"loop", "+loop", ":", ":noname". Если ты собираешься извращаться
с "cs-roll", потребуется подправить "then" и "else". Ну и всё!
> Учти также, что если ты не хочешь использовать стековую модель
> (которая не подходит для этих целей из-за нелокальности, согласен?
> то тебе по-любому придётся писать свой интерпретатор
Зачем?
> на нормальном языке это легче.
Спорно.
> Более того, я хотел добавить, что единственным преимуществом
> форта является уже написанный лексер, но потом понял, что и это
> скорее недостаток: нам гораздо удобней генерить программы в
> уже распарсенном виде, и так же их интерпретировать.
Этого у тебя никто не отнимает. Даже проще: при использовании
форта у тебя есть парсер и сериализация, если ты готов немного
похакать, у тебя уже есть кодогенератор и интерпретатор.
>> (Кстати, расскажи, чем так принципиально отличаются комбинаторы
>> от лямбда-выражений. Я хочу послушать.)
> У лямбд есть именованные (или нумерованные) параметры. Это -
> нелокальность. Нелокальность - зло.
Нелокальность чего? Или ты про область видимости?
Не понимаю, где ты нашёл проблему, всю жизнь комбинаторы были
просто краткими обозначениями лямбда-выражений. Есть правила
эквивалентных преобразований из одного в другое.
---
"Мы продолжаем то, что мы уже много наделали."
>> не просто, а очень просто. По крайней мере, я не вижу в этом
>> трудности.
> И как? В смысле, бесконечные циклы как отлавливать? Подпатчить
> все слова, даваемые агентам, так, чтобы они проверяли счётчик
> и выпадали наружу, если он больше заданной величины? А в чём
> тогда вообще смысл использовать форт-то, если подобная
> виртуальная машина на нормальном языке пишется быстрее,
> выглядит проще, отлаживается легче, да и работает наверняка
> быстрее?
Зачем "все"? Достаточно подпатчить "again", "until", "repeat",
"loop", "+loop", ":", ":noname". Если ты собираешься извращаться
с "cs-roll", потребуется подправить "then" и "else". Ну и всё!
> Учти также, что если ты не хочешь использовать стековую модель
> (которая не подходит для этих целей из-за нелокальности, согласен?
> то тебе по-любому придётся писать свой интерпретатор
Зачем?
> на нормальном языке это легче.
Спорно.
> Более того, я хотел добавить, что единственным преимуществом
> форта является уже написанный лексер, но потом понял, что и это
> скорее недостаток: нам гораздо удобней генерить программы в
> уже распарсенном виде, и так же их интерпретировать.
Этого у тебя никто не отнимает. Даже проще: при использовании
форта у тебя есть парсер и сериализация, если ты готов немного
похакать, у тебя уже есть кодогенератор и интерпретатор.
>> (Кстати, расскажи, чем так принципиально отличаются комбинаторы
>> от лямбда-выражений. Я хочу послушать.)
> У лямбд есть именованные (или нумерованные) параметры. Это -
> нелокальность. Нелокальность - зло.
Нелокальность чего? Или ты про область видимости?
Не понимаю, где ты нашёл проблему, всю жизнь комбинаторы были
просто краткими обозначениями лямбда-выражений. Есть правила
эквивалентных преобразований из одного в другое.
---
"Мы продолжаем то, что мы уже много наделали."
Оставить комментарий
tita46
Здравствуйте!Существует ли такой интерпретатор функционального языка программирования, который бы позволял (достаточно легко) создавать потоки (многопоточность) и при этом ограничивать их в размере памяти и во влиянии на компьютер, навроде виртуальной машины? И чтобы потоки могли обмениваться друг с другом сообщениями?
Хочу написать искусственную жизнь. Точнее, одну я (почти) написал http://erg.biophys.msu.ru/lamarckathome/forum/ , но на основе языка Форт, и под конец я осознал, что это несколько не то, что надо в данном случае. А вот инкапсуляция, свойственная функциональным языкам, была бы весьма кстати. Правда, сам я, к сожалению, в ФП дуб дубом.
Заранее благодарен.
З. Ы. На дату прошу не обращать внимания..
З. З. Ы. А почему это я анонимусом отобразился? Это тоже связано с датой?