Будет уменьшать количество объектов, состояние которых программист должен учитывать в один момент времени. Если он оперирует ситуацией, то держит в голове только объекты задействованные в ней.
Ну вопросы самомодификации наверное не сильно актуальны для обычных программ. Я потому и указал для статьи раздел «машинное обучение». А стало быть она так или иначе затрагивает область интеллекта (пока не СИИ) и это стоит учитывать.
Код это набор инструкций, изменение которого может привести к изменению поведения (внешнему отражению). А может изменять глубинные процессы, которые на поведении не факт, что отразятся
Я бы попросил не использовать этих саркастических выпадов.
Давайте уходить от бихейвиористической оценки поведения интеллекта. Изменение поведения это только часть самомодификации.
Степень того, насколько программа может отклоняться от навязываемого ей, может быть изначально жестко задано. В таком поведении может быть и плюс. Например мы говорим программе «найти то-то», а она сама выбирает самый быстродействующий алгоритм (из тех, что она уже знает) поиска, при этом может сразу же протестировать его и сменить, если другой показывает более лучший результат для конкретно этой задачи.
Процесс обучения (изменение поведения) с учителем. Когда у учителя нет непосредственного доступа к коду. При этом процесс программирования может проходить не в императивном режиме, как сейчас, а в консультанционном, в режиме коммуникации, обсуждения (на самом высшем уровне взаимодействия)
(мене важный) приносит ли способность програм к самомодификации выигрыш при их написании и поддержке?
Тут главное, что мы ожидаем от этого, и что получим в результате. Всем известно, что программист во время написания кода должен сосредотачиватся, чтобы держать как можно больше объектов в голове. Если программа сама будет брать на себя хотя бы это, уже будет выиграш. Меньше нагрузка на мозг, меньше ошибок.
(более важный) действительно ли предлагаемая парадигма упрощает написание самомодифицирующихся программ?
Тут стоит разделить на самомодификацию с учителем и без. С учителем однозначное да. По тому видео вы возможно и сами это понимаете, но не хотите признавать. Т.к. там приведен яркий пример ситуативного программирования. Что касается обучения без учителя, то на данный момент нет. Вернее я пока такой возможности не вижу, но она потенциально присутствует. Собственно я много чего не видел, до начала реализации. Только не спрашивайте чего именно не видел, т.к. конкретно ответить не смогу. Не видел в целом картины взаимодействия компонентов, так, как вижу ее сейчас. И это видение постоянно расширяется в результате обсуждений и попыток реализации. При этом важно как первое, так и второе, даже неизвестно что важенее больше. Я к тому, что не реализовав подход, мы этого не узнаем наверняка.
За время переписки я достаточно о вас узнал, чтобы предугадать это.
вы правда думаете, что в искусственном интеллекте самомодификация заменяет написание и поддержку кода?
Нет, там работает CLIPS, которая просто модифицирует правила.
Вы про искусственный интеллект вроде ботов в играх, или про сильный искусственный интеллект, сродни человвеку? Если первое, то эти примитивы создает и поддерживает программист, а самомодификация заменяется адаптивным алгоритмом. Что же до сильного ИИ, то я не знаю, как он устроен, т.к. его еще не создали. Потому не помешает рассмотреть и возможность такого подхода.
Конечно же со временем и он может быт заменен на что-то более результативное.
А о том, как с набегу проверить теорию на одном из существующих языков (в плане использования в обработчиках ситуаций например С++, или С#) честно говоря не думал.
Опробация в процессе и началась не вчера. В разработке я объединил этот подход с другим, который заключается в том, что язык исполнения = языку общения (коммуникации). Т.е. программные инструкции выглядят, практически как естественный язык. На нем же предполагается и описание действий (программирование) интеллектуальной системы, чтобы не лезть в код. Это я по поводу присоединиться. Проект открытый, но если этот подход проблемно встречают, то тот точно засрут.
Действительно, этот момент не был рассмотрен в статье автора. Неявно как бы предполагалось, что все подписки и отписки сделаны во время инициализации.
Условия (так сказать триггеры) могут создаваться к значениям переменных непосредственно в рантайме. Как и группироваться в новые ситуации. Если я правильно понял про подписку.
Если в алгоритме переменная используется в нескольких местах по-разному.
Не совсем понятно, как это по-разному.
Есть переменная eng_state, например, ознаначающая состояние двигателя (включен/выключен) и содержащая значения TRUE либо FALSE. К одному значению переменной можно создать только одно условие (в старом варианте — событие). Плюс одно общее условие на изменение значения переменной с любого на любое. Т.е. условие eng_state==TRUE активируется в момент изменения значения с FALSE на TRUE. Если это условие привязано к каким-то ситуациям, то оно может спровоцировать и их активацию, следовательно вызывать обработчики тех ситуаций.
Можно дать условию eng_state==TRUE символическое имя 'Двигатель включен' и обращаться к условию уже через него. Т.е. при объяснении системе с какой конкретно ситуацией мы хотим работать (изменить) можно так и указывать Если 'Двигатель включен' то… (набор инструкций)
Чистое реактивное программирование, в моем понимании, это автоматический пересчет ячеек в экселе. Для табличного процессора этого хватает, но для реального программирования это ограниченный подход. Приходится городить всякие «реакторы» или события. Возможно именно этот подход используется в каких-то реактивных языках, которых похоже довольно много.
Тогда элементарные условия будут двух типов: события и состояния.
Это хорошо заметно, если давать таким условиям символические имена. Например условие 'Двигатель работает' явно имеет преобладающей тип состояния. А условие 'Соперник совершил ход' имеет преобладающий тип события.
Давайте уходить от бихейвиористической оценки поведения интеллекта. Изменение поведения это только часть самомодификации.
Нет, там работает CLIPS, которая просто модифицирует правила.
Вы про искусственный интеллект вроде ботов в играх, или про сильный искусственный интеллект, сродни человвеку? Если первое, то эти примитивы создает и поддерживает программист, а самомодификация заменяется адаптивным алгоритмом. Что же до сильного ИИ, то я не знаю, как он устроен, т.к. его еще не создали. Потому не помешает рассмотреть и возможность такого подхода.
Конечно же со временем и он может быт заменен на что-то более результативное.
youtu.be/Dtkz5tj-SlY?t=5837
Условия (так сказать триггеры) могут создаваться к значениям переменных непосредственно в рантайме. Как и группироваться в новые ситуации. Если я правильно понял про подписку.
Не совсем понятно, как это по-разному.
Есть переменная eng_state, например, ознаначающая состояние двигателя (включен/выключен) и содержащая значения TRUE либо FALSE. К одному значению переменной можно создать только одно условие (в старом варианте — событие). Плюс одно общее условие на изменение значения переменной с любого на любое. Т.е. условие eng_state==TRUE активируется в момент изменения значения с FALSE на TRUE. Если это условие привязано к каким-то ситуациям, то оно может спровоцировать и их активацию, следовательно вызывать обработчики тех ситуаций.
Можно дать условию eng_state==TRUE символическое имя 'Двигатель включен' и обращаться к условию уже через него. Т.е. при объяснении системе с какой конкретно ситуацией мы хотим работать (изменить) можно так и указывать Если 'Двигатель включен' то… (набор инструкций)
Это хорошо заметно, если давать таким условиям символические имена. Например условие 'Двигатель работает' явно имеет преобладающей тип состояния. А условие 'Соперник совершил ход' имеет преобладающий тип события.