Форум: Проблемы искусственного интеллекта

Регистрация | Вход

Все темы | Новая тема  Стр.38 (60) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: Поиск новых идей - пути выхода из кризиса
r Сообщений: 837	На: Поиск новых идей - пути выхода из кризиса Добавлено: 20 апр 16 16:26 Изменено: 20 апр 16 16:29 Цитата: Автор: Vpolevoj Программирование (а планирование - это вид программирования), которое отталкивается от ситуации (как это предлагает делать r), становится невозможным, так как описание любой ситуации должно включать в себя ВСЕ переменные ВСЕХ объектов рассматриваемого в модели, даже "замкнутого" мира. И любое изменение любой из этих переменных будет означать новую ситуацию. А если мы хотим, чтобы хотя бы часть из этих переменных в некоторых случаях не учитывалась (а в других бы наоборот - учитывалась), то такая задача превращается в нечто вроде "гадания на кофейной гуще". Не соглашусь. Описание любой ситуации должно включать в себя только переменные, которые важны для этой ситуации и в ней участвуют. Если у автомобиля нет датчика дождя на лобовом стекле, то он не узнает идет дождь, не идет, и есть ли такое явление вообще. Бортовой компьютер автомобиля просто недополучит кусок информации об окружающем мире. А если датчик есть, то для автоматического включения дворников системе не нужно знать, загорелись ли стоповые сигналы впереди идущего транспорта, или нет. Любое прогнозирование превращается в гадание на кофейной гуще. Просто его точность напрямую зависит от объема и достоверности получаемой информации. Недополучил кусок информации - дворники включит кто-то за тебя. Есть люди, которые знали что случится кризис на рынке недвижимости в 2008 году и говорили мне тогда, что нужно продавать недвижимость. Продав тогда квартиру, сейчас на те же деньги можно купить 3 таких. А есть люди, которые и сейчас не понимают, что это было.. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Поиск новых идей - пути выхода из кризиса Добавлено: 20 апр 16 20:51 Цитата: Автор: r Цитата: Автор: Vpolevoj Программирование (а планирование - это вид программирования), которое отталкивается от ситуации (как это предлагает делать r), становится невозможным, так как описание любой ситуации должно включать в себя ВСЕ переменные ВСЕХ объектов рассматриваемого в модели, даже "замкнутого", мира. И любое изменение любой из этих переменных будет означать новую ситуацию. А если мы хотим, чтобы хотя бы часть из этих переменных в некоторых случаях не учитывалась (а в других бы наоборот - учитывалась), то такая задача превращается в нечто вроде "гадания на кофейной гуще". Не соглашусь. Описание любой ситуации должно включать в себя только [те] переменные, которые важны для этой ситуации и в ней участвуют. Если у автомобиля нет датчика дождя на лобовом стекле, то он не узнает идет [ли] дождь, [или] не идет, и есть ли такое явление вообще. Бортовой компьютер автомобиля просто недополучит кусок информации об окружающем мире. А если датчик есть, то для автоматического включения дворников системе не нужно знать, загорелись ли стоповые сигналы впереди идущего транспорта, или нет. Любое прогнозирование превращается в гадание на кофейной гуще. Просто его точность напрямую зависит от объема и достоверности получаемой информации. Недополучил кусок информации - дворники включит кто-то за тебя. Соглашаться или нет - это ваше право. Я вон тоже с Виктором не соглашаюсь... Но если обработчики "ситуаций" (в вашей терминологии) срабатывают не на все изменения среды, а только на некоторые, которые, как вы говорите, "участвуют в этой ситуации", то это уже будет не "ситуация" (как её не назови), а "сигнал", как например, сигнал от датчика дождя на лобовом стекле автомобиля в вашем примере. И процесс запуска обработчиков этих "сигналов" как нельзя лучше иллюстрируется механизмом так называемых аппаратных прерываний у процессора. Пришло прерывание по определенному каналу - запустился соответствующий обработчик. Можно сделать такие сигналы и составными, если на входе будет регистр, а сигнал прерывания всего лишь будет указывать процессору, что состояние этого регистра изменилось, тогда запуск нужного обработчика будет зависеть от конкретного значения этого входного регистра. К тому же у процессоров есть и так называемые программные прерывания, и тогда обработчик любого "события" можно создавать и вызывать программно. Вот так мы от "ситуаций" плавно перешли к "сигналам" и "событиям", то есть, не к анализу полной обстановки, что вы же сами считаете совершенно ненужным, а к реакции на вполне конкретные локальные изменения, на которые как раз-таки можно навешивать свои обработчики. И "Сигналы" и "События", кстати, могут быть составными, как я уже говорил. Но в любом случае, если мы перестаём оперировать понятием "ситуация" (хотя, возможно, все дело просто в терминологии), так как считаем ненужным оценивать полное состояние всех переменных окружающего мира, и переходим к терминам "Сигнал" и "Событие", то значит, что мы отходим и от самой парадигмы "ситуационного программирования" и возвращаемся назад, к обычному ООП с его обработчиками Ивентов (событий). Ну и - Слава Богу. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Нейрон Добавлено: 20 апр 16 22:09 Изменено: 20 апр 16 23:29 Цитата: Автор: r Цитата: Автор: Vpolevoj Значит, условие (которое r называет "ситуацией") - "Идет дождь" и "Собираемся выйти на улицу". Его можно запихнуть в первый блок проверки моей схемы (While). Тут есть один непонятный момент. Кто будет запихивать? В том плане, что если это будет делать человек через коммуникацию, то ему придется указывать системе в какой именно блок нужно добавлять правила. А блоков таких могут быть тысячи. Если система сама будет добавлять, то ей тоже нужно знать куда именно. Т.е. в обоих случаях нужно как-то адресовать изменяемые блоки. Допустим, если процесс программирования будет идти через диалог, и нужно будет в блок, описывающий ситуацию "(идет дождь, мы выходим на улицу)->Взять зонт" добавить новое ограничение, скажем такое "(идет дождь, мы выходим на улицу, для передвижения будет использоваться личный автомобиль)->зонт не брать". Тут получается второе условие является вложенным в первое, т.к. оно покрывает только часть первого. Таким образом в случаях, когда планируется передвижение пешком, или на общественном транспорте, система воспользуется рекомендацией из более общего первого правила и возьмет зонт, а в случае использования личного транспорта, воспользуется рекомендацией из более частного второго условия и не возьмет. Как планируется определять в какие блоки добавлять эти рекомендации? Попробую немного описать, как я себе представляю, должен происходить процесс диалога с такой системой. Предположим, что мы захотели заложить в неё новый обработчик "события" из этого примера, то есть, "Хотим выйти на улицу", проверяем "Идет ли дождь", и берем или не берем зонтик (пока без учета автомобиля - это мы попробуем добавить потом). И как же это можно сделать? Значит, обращаемся мы к нашей системе. И пишем ей: "Создать новую команду" (или "Создать новый обработчик" - нужно заранее определить, как будет выглядеть эта команда). Что должна делать система, когда встретит такую команду? Она автоматически создаст у себя в базе новую строку, которая будет соответствовать одному полноценному блоку Универсального алгоритма, и присвоит ему какое-то внутреннее имя (типа N223, или RV15 - нужно придумать, как система будет генерировать эти свои внутренние имена для процедур и переменных, но человеку это имя все равно будет не видно), а во всех созданных блоках этого алгоритма она автоматически вставит так называемые заглушки: в блоках условий (While и Until) вставит логические единицы - ИСТИНА, а в вместо процедурных блоков "пустой оператор", который не будет ничего делать. И - всё - обработчик создан, и он уже готов к работе, поскольку формально он - безупречен, и может быть даже запущен прямо сразу же после своего создания, и выполнится без единой ошибки. Но нам же от него требуется, чтобы он что-то делал, и делал при этом что-то осмысленное. Поэтому мы продолжаем с ним работать дальше. Например, мы даем ему собственное имя. А для этого мы говорим программе: Присвой имя [этому обработчику] "Выйти на улицу". И программа присвоит ему это имя. Но нет, она не заменит своё, уже присвоенное процедуре и автоматически сгенерированное ею имя на это - новое - это было бы глупо, и нарушило бы целостность вызовов, если такие, к примеру, уже бы сформировались. Она просто заполнит соответствующее поле - никнейм (или алиас) этой процедуры. И тогда человек может обращаться (указывать) к этой процедуре по её никнейму (алиасу), что ему делать гораздо удобнее, а программа по-прежнему будет использовать для работы с этой процедурой своё внутреннее имя. И вот, имя процедуре мы присвоили, что дальше? А дальше мы хотим, чтобы эта процедура срабатывала на какое-то условие. А там пока во всех блоках проверки стоят логические единицы (но мы об этом не знаем, либо знаем, но молчим). И вот, мы пишем программе: Первое условие "Выйти на улицу". Надо сказать, что для того, чтобы программа понимала, в какой именно блок она должна внести изменения, нужно все эти блоки как-то обозначить. Для начала можно просто присвоить им всем порядковые номера (как это сделал я в своей блок-схеме), и тогда можно прямо писать "в блоке 5 напиши то-то и то-то," или "замени в блоке 2 условие на "..."" и т.д. А можно переопределить эти названия, и присвоить некоторым (или даже всем) блокам в схеме Универсального алгоритма свои собственные имена, скажем, блоки проверки назвать Первым условием и Вторым условием (их же в схеме всего два), а можно обозвать их Входным условием и Выходным условием, а можно дать этим блокам разные имена и названия, и тогда у нас получатся синонимы, а машина будет понимать любое к ним обращение. И вот, значит, мы говорим программе, что Первое условие должно быть (можно писать "=", или слово "ЕСТЬ" - опять же дело в том, как мы определим слова диалога) "Выход на улицу". Что делает программа? У неё там (к этому моменту), как я уже и говорил, стоит логическая единица - ИСТИНА. Но это также означает, что переменная под эту "логическую единицу" уже существует - она уже создана и программа ей уже присвоила какое-то свое внутреннее имя. Таким образом, делать ей, на самом деле, ничего не нужно, и она просто присвоит этой уже существующей у неё переменной очередной никнейм (или алиас) - "Выход на улицу". А внутри это будет выглядеть так: вместо выражения While (TRUE) будет While ('Выход на улицу'), только вместо текстового никнейма (алиаса) она будет подставлять внутреннее имя этой своей переменной. Но тут наша программа впервые сталкивается с ситуацией неопределенности. Мы задали переменную (на самом деле - всего лишь дали ей собственное имя), но таким образом мы показали программе, что у нас есть интерес к этой переменной и что её значение может меняться, а у неё там - логическая единица. Что она должна сделать в этом случае? Она должна сама спросить у человека: "Откуда брать значение "Выход на улицу"? Так как значение любой переменной может быть получено из других процедур, а так же быть вычисленным и т.д. В данном же случае человек ответит программе: "Запросить" (и это тоже должна быть одна из оговоренных заранее команд), и программа в ответ на это кодовое слово сформирует у себя (в каком блоке?) в блоке номер 1 (поскольку он единственный, который стоит перед условным блоком, и отвечает за инициацию переменных) запрос на ввод этой логической переменной. И программа в диалоге потребует уточнений: "Текст запроса?" А мы введем ей: "Желаешь выйти на улицу? Да/нет" Этот текст будет появляться на экране при вызове этой процедуры, и мы должны будем ответить на него либо словом Да, либо словом Нет, а программа подставит в свою логическую переменную либо TRUE, либо FALSE (либо 1 и 0). С этим определились. Что дальше? А дальше у нас должно быть само действие. Программа, кстати, ничего больше не делает, а зачем - у неё и так все хорошо, все работает, проблем и ошибок нет. Это - нам надо. Поэтому мы пишем: "Выполняем действие - выход из дома." Куда это следует поместить? В какой блок? Теоретически - можно в любой процедурный блок, который стоит ниже условного блока While, так как блок Until мы не используем, веток у нас в блоке case нет (всего одна), поэтому, теоретически, куда угодно, но... Если, к примеру, мы поместим это действие в самый последний блок (номер 7), то в случае, если мы на запрос ответим Нет, то значит и выходить из дома нам не надо, то есть, в этот блок помещать это действие нельзя. Поэтому у нас остаются блоки 3, 4, 5. Но, предположим, что мы добавим ветки в блок case (а вдруг!?), значит, основное действие, которое будет оставаться неизменным, если уж мы выбрали вариант ответа Да, нужно поместить в блок номер 5, и только туда! Можно это указать явно, сказать программе "В блок номер 5...", а можно и не говорить - сделать этот процесс по-умолчанию. Но она же должна при этом еще и что-то сделать. Поэтому пишем: Вывести на экран "Доброго пути!" И программа поместит в это блок (номер 5) стандартную команду (которая уже должна у неё быть), типа, Print "Доброго пути!" (или ?"Доброго пути!" - это уж как мы сами определим). Итак, наша программа уже готова, и вполне себе работоспособна. Если её запустить (вызвать на исполнение командой "Запустить 'Выход на улицу'"), то она сначала выведет на экран запрос "Желаешь выйти на улицу? Да/нет", отвечаем ей Да или Нет, и если мы ответим Да, то она напишет нам "Доброго пути!", а если мы ответим ей Нет, то она ничего не напишет. Далее мы хотим добавить ей в этот обработчик ситуацию с дождиком и зонтом. Как это можно сделать? Поступаем аналогичным образом. Пишем: "Создать новый обработчик". Программа создает новую запись в своей БД. Пишем: "Присвоить имя "Дождик" (или "Зонтик" - как хотите). Программа присваивает этой только что созданной процедуре собственное имя. Пишем: "Первое условие "Идет дождь". Программа обзывает первую логическую переменную, которая у неё уже создана, этим именем, и спрашивает у нас, откуда ей брать её значение. Мы ей говорим, либо запроси (у нас) и тогда она сформирует точно такой же запрос, как и в случае выхода из дома, либо укажем ей на датчик, если компьютер, скажем, подключен к внешним датчикам (состояние этого датчика должно быть либо 1, либо 0). Предположим, что мы выбрали первый вариант - запрос. И тогда программа попросит нас набрать текст приглашения. Мы вводим: "На улице идет дождь? Да/Нет" Запрос сформирован. Пишем: "Действие - Взять зонт" (это, как вы наверное уже и сами догадались, всего лишь никнейм (или алиас) для блока действия под номером 5). И далее пишем: "Вывести текст "Возьми зонт!". Программа поместит в блок номер 5 команду ?'Возьми зонт!' Все - и эта процедура готова! Можно её даже запустить и посмотреть, как она будет работать. А теперь нам нужно их как-то объединить. Но как? Пишем: "Редактировать "Выход на улицу". Программа делает активной процедуру "Выход на улицу" (перемещает указатель на соответствующую запись в Базе Данных). Пишем: В блоке 4.1 (или, если у него будет своё собственное имя - то по имени) вызвать процедуру "Зонтик". Всё. Программа вместо существующей там "заглушки" подставит ИМЯ созданной нами процедуры "Зонтик", только не само это имя, а - имя внутренней переменной, которое программа присвоила этой процедуре, когда мы её создавали. Можно запускать. Пишем: Выполнить "Выход на улицу". Программа выводит запрос: "Желаешь выйти на улицу? Да/нет", отвечаем ей Да, она пишет "На улице идет дождь? Да/Нет", и если мы тоже отвечаем ей Да, то она напишет нам "Возьми зонт!" и следом "Доброго пути!", если же мы ответим ей Нет, то она просто выведет на экран "Доброго пути!". Аналогично, я считаю, можно добавить сюда еще один обработчик, например, с автомобилем. А для этого нужно внутрь процедуры "Зонтик" вставить еще один созданный отдельно алгоритм обработки условия "Автомобиль" и поступить с ним точно так же, как и с "Зонтиком". Только там, если мы едем на автомобиле, то зонтик не берём. Вот и все. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Поиск новых идей - пути выхода из кризиса Добавлено: 20 апр 16 23:12 Изменено: 20 апр 16 23:52 Цитата: Автор: victorst Классы в онтологиях в отличие от ООП могут представлять неполное описание мира. Это позволяет расширять классы в процессе работы ИИ. Т.е. онтологичесое описание подходит для незамкнутого мира и основано на точной математической модели. Если взять, к примеру, OWL DL, то здесь гарантировано, что интеллектуальный агент выполнит логический вывод за ограниченное время. Реификация (материализация, овеществление утверждений) С помощью реификации можно выражать субъективные суждения (свои и чужие), хранить их, и использовать в процессе функционирования ИИ включая общение. Мне не совсем понятно, Виктор, что ты пытаешься нам показать/доказать? Что всё (украдено) придумано и сделано до нас? Что всё уже есть? Но я так не думаю. Мало того, я вижу, что во всех этих, таких крутых и навороченных с виду, системах описания мира - онтологиях, и в системах для организации процессов планирования - существует масса проблем. И зачастую - неразрешимых проблем. Сколько бы они эти свои системы не усложняли и не совершенствовали. А почему? Почему я так считаю, и почему у них (как я думаю) ничего не получится? А потому, что мир не описывается с помощью подобных формализованных онтологий - просто потому, что он - не такой. Он не вписывается ни в одну из любых формализованных систем описания, какие бы мы не придумывали, хоть закрытые, хоть открытые. Потому что формализованные системы описания - это всего лишь небольшая часть из возможного набора подходов, причем, не самая сильная. Я отношу её к уровню Сознания (по Симонову). А Сознание, к сожалению, не самый мощный инструмент нашего мышления. Но людям он ближе и понятнее, вот они и пытаются поэтому описать все только лишь с его помощью - стараются натянуть "сову" (в оригинале - гандон) на глобус. А он у них всё никак не натягивается и постоянно рвётся. Так же и с онтологиями. То, что ты (и не в первый раз уже) указываешь нам на "реификацию", то есть, на придание сообщению (утверждению) признака авторства (хотя вы и называете это почему-то материализацией - но откуда тут материализация?), то это вовсе не делает это описание (сообщение) субъективным. Просто ему присваивается еще один признак - кто автор - только и всего. То есть, это означает, что такое-то утверждение сделал тот-то (автор). И что? И - ничего. Еще один признак - и всё. Как они там сами же пишут, любой (автор) может сделать любое, даже ложное, или даже бессмысленное утверждение. И система это поддерживает. Ну, и - зачем? [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Нейрон Добавлено: 22 апр 16 11:19 Изменено: 22 апр 16 11:41 Цитата: Автор: r Допустим, если процесс программирования будет идти через диалог, и нужно будет в блок, описывающий ситуацию "(идет дождь, мы выходим на улицу)->Взять зонт" добавить новое ограничение, скажем такое "(идет дождь, мы выходим на улицу, для передвижения будет использоваться личный автомобиль)->зонт не брать". Про автомобиль. В прошлый раз, когда я объяснял, как можно через диалог обучить программу какому-нибудь алгоритму, то я остановился на том, что в случае, если мы, выходя из дома, планируем перемещаться на автомобиле, то - зонт не брать. И я написал тогда, что эта ветка алгоритма делается точно так же (добавляется в ветку зонта). Но немного подумав, буквально в тот же день, я понял, что "автомобиль" не вписывается в эту ветку - там алгоритм другой. Потому что, когда мы едем на автомобиле, то нам, по большому счету, плевать, какая там погода, то есть, мы не просто не берем с собой зонт, а - вообще не смотрим, идёт ли там дождь, или не идёт. Но вот я это понял, подумал еще немного, стоит ли отредактировать тот свой пост, и внести правки, с указанием этого открывшегося момента, но решил, что не стоит, так как там я просто показывал сам процесс диалога, и про "автомобиль" упомянул лишь вскользь, сказав, что добавить еще одно условие можно - и всё. Поэтому, есть ли там отличия и особенности - нет ли их, я в том своем примере в эти нюансы не углублялся. И поэтому я решил, что ничего ни добавлять ни объяснять не буду, кто умный - тот и сам до этого момента дойдет. Но вот прошло еще два дня... И я подумал, что это мог бы быть хороший пример ситуации, когда вдруг потребовалось внести правки в уже существующий алгоритм. Тем более, не просто добавить, или усложнить (дописать), а буквально - перекроить, переделать. И тогда я решил вернуться к этому примеру. И начнём мы с ситуации, когда наш прежний алгоритм (с "зонтом") мы уже сделали и он работает, но нам потребовалось внести в него изменения с "автомобилем". И, допустим, мы пока не знаем, куда и как мы будем "запихивать" это условие. Начинаю. Включаем компьютер и запускаем свою программу. Когда появляется диалоговое окно, пишем в нём: "Создать обработчик "На автомобиле"" (создает). Первое условие: "На автомобиле" (присваивает имя логической переменной). По запросу (создает запрос). Текст приглашения: "Поедешь на автомобиле? Да/нет" (сделала). Но тут выясняется, что когда мы говорим, что Да, то есть, что мы поедем на автомобиле, то как раз-таки именно в этом конкретном случае нам делать ничего и не нужно, ни зонтик с собой брать, ни даже погоду смотреть. А вся трихомудь разворачивается совсем в другой ветке - там, где Нет. Что делать? В обычной программе, когда мы программируем ручками, мы вместо аргумента А пишем НЕ(А), поэтому, наверное, так же можно поступить и здесь. И мы пишем своей программе: "Первое условие НЕ ("На автомобиле"), а она, соответственно, поставит у себя это условие, и пропустит исполнение на основную ветку только тогда, если мы "НЕ поедем на автомобиле". Больше нам с этой процедурой делать, вроде бы, нечего, поэтому переходим к старому алгоритму. Пишем: "Редактировать "Выйти на улицу"" (программа делает активной эту запись). Там у нас только один исполняемый блок - 4.1 - где происходит вызов процедуры, в которой мы проверяем погоду, и если идет дождь, то мы берем с собой зонтик. А нам теперь это не надо, так как у нас теперь - автомобиль. Поэтому мы пишем: "Блок 4.1 "На автомобиле"". И программа вместо бывшего там до этого вызова процедуры "Зонтик" вставит вызов процедуры "На автомобиле". И общий алгоритм станет таким: Мы хотим выйти из дома -> программа спрашивает у нас, хотим ли мы выйти, мы отвечаем Да -> и программа вызывает процедуру "На автомобиле", в которой она нас спрашивает, поедем ли мы на автомобиле -> и если мы ответим, что Да, поедем, то ничего не произойдет, управление вернется назад к вызвавшей процедуре "Выход из дома", и программа напишет нам "Доброго пути!" А вот если мы ответим ей Нет, что мы не поедем на автомобиле, то как раз в этом случае нам и потребуется посмотреть на погоду, и, если там идет дождик, взять с собой зонт. Значит, что мы должны сделать? Мы пишем: Редактировать "На автомобиле" (программа делает активной эту запись). Пишем: Блок 4.1 "Зонтик" (программа вставляет в этот блок вызов процедуры "Зонтик"). И?... И - всё! Как видите, действий для внесения изменений в уже существующий алгоритм потребовалось не так уж и много. (Сравните, если бы то же самое пришлось бы сделать в обычной программе.) Отлаживать ничего не пришлось (поскольку это не нужно, так как все блоки универсальные и они всегда находятся в рабочем состоянии). Важно было лишь отслеживать логику, чтобы не запутаться самому, и программа выполняла бы именно то, что от неё требуется. Короче, не знаю, как вы, а я, пожалуй, сделаю для себя такую игрушку. [Ответ][Цитата]
r Сообщений: 837	На: Поиск новых идей - пути выхода из кризиса Добавлено: 23 апр 16 5:07 Изменено: 23 апр 16 5:13 Цитата: Автор: Vpolevoj Вот так мы от "ситуаций" плавно перешли к "сигналам" и "событиям", то есть, не к анализу полной обстановки, что вы же сами считаете совершенно ненужным, а к реакции на вполне конкретные локальные изменения, на которые как раз-таки можно навешивать свои обработчики. И "Сигналы" и "События", кстати, могут быть составными, как я уже говорил. Но в любом случае, если мы перестаём оперировать понятием "ситуация" (хотя, возможно, все дело просто в терминологии), так как считаем ненужным оценивать полное состояние всех переменных окружающего мира, и переходим к терминам "Сигнал" и "Событие", то значит, что мы отходим и от самой парадигмы "ситуационного программирования" и возвращаемся назад, к обычному ООП с его обработчиками Ивентов (событий). Ну и - Слава Богу. Нужно наоборот, от событий переходить к ситуациям. Я думаю ситуации это в вашем понимании составные события. Да у меня события есть, более того, не только события, а и состояния. Оба понятия я называю триггерами. Триггер состояния может находится в одном из двух положений продолжительное время. Триггер события принудительно сбрасывается после возникновения события. Из комбинации триггеров можно составить условие (ситуацию). Да, можно навешивать обработчики для событий и состояний, все как в ООП, но важнее что можно навесить обработчик на комбинацию событий и состояний - на ситуацию. Триггеры имеют только два логических значения: да/нет, true/false. Т.е. он может быть либо взведен, либо нет. Систему триггеров-ситуаций можно представить в виде, например, доски с тремя тумблерами и двумя лампочками. Допустим тумблеры и лампочки соединены таким образом, что первая лампочка загорается только когда первый и второй тумблеры включены, а вторая лампочка загорается только когда второй и третий тумблеры включены. Таким образом имеем три триггера (тумблеры), две независимые ситуации (первый и второй тумблеры включены; второй и третий тумблеры включены), и два обработчика ситуаций (лампочки). Можно обратить внимание, что второй тумблер (триггер) подвязан к двум разным ситуациям. Такого механизма в ООП нет, вернее ситуации там просто описываются ифами. Да и вообще, при чем тут ООП. ООП это когда переменные и функции не болтаются в воздухе а привязаны к объектам и доступ к ним осуществляется посредством указания сперва имени объекта, а потом уже свойства (переменной) или метода (функции). Ну вы это и так знаете. Наличие событий это так, дополнение, хотя и очень удачное. Не совсем понял про анализ полной обстановки. В процессе объяснения (программирования) человек описывает ситуацию (условие) при помощи набора триггеров известных системе, после чего он описывает действия которые необходимо выполнить при наступлении условия. Далее, в процессе работы, триггеры постоянно меняют свои значения, а система их мониторит. Как только для какой-то ситуации активировался последний неактивный триггер (все триггеры ситуации стали активными), вызывается обработчик этой ситуации. И самое важное, для чего нужен ситуативный подход. Для адресации. Я уже намекал вам, когда спрашивал как планируется адресовать место, в которое требуется внести изменение. Т.е. задача-то какая? Добавить новый функционал в механизм коммуникативным путем. Но перед тем, как добавить нужно определиться с тем куда добавлять. Допустим с тем, что добавлять понятно - человек знает набор методов, которые система поймет и выполнит. Часть из этих методов вшиты с завода, а остальные создаются объяснением, на основе вшитых. Например, система знает как определить место нахождение стакана и знает как перенести манипулятор в нужную точку. На основе этих методов можно создать новый метод по переносу стакана в другое место. Т.е на базе двух конкретных методов будет создан новый, более абстрактный. Который в свою очередь потом будет участвовать в еще более абстрактном методе - команде "принеси попить". В общем я думаю с тем, что добавлять ясно. Вернемся к тому, куда добавлять. Я не говорю, что ситуационный подход идеален, но ваш блочный подход менее гибкий, т.к. блоки будут крупные. Как я понял, на жарку яичницы будет всего один блок, а это большой процесс, очень много кода в одном блоке будет. Т.е. имеем все то же программирование с кучей ифов, для которого необходим анализ больших блоков кода. А что делать, если диалог будет вестись исключительно голосом? Когда же мы описываем машине ситуацию на основе известных ей триггеров мы конкретно адресуем то место в которое хотим внести изменения. Не нужно копаться в коде, искать соответствующий иф и ломать голову как его подправить. [Ответ][Цитата]
r Сообщений: 837	На: Поиск новых идей - пути выхода из кризиса Добавлено: 23 апр 16 6:01 Изменено: 23 апр 16 8:37 Попробую описать пресловутый процесс жарки яичницы. Допустим система знает о таких триггерах (узнает их в диалоге и активирует в процессе работы): - Получена команда "приготовить яичницу" - Сковорода разогрета - Яичница готова А так же может выполнять следующий набор действий: - Поставить сковородку на плиту - Включить плиту - Выключить плиту - Налить масла - Разбить яйца - Посолить - Накрыть крышкой - Установить таймер на N минут Тогда процесс объяснения (программирования) будет состоять из описания 3х ситуаций. В круглых скобках набор триггеров ситуации, в фигурных содержимое обработчика ситуации. ( Получена команда "приготовить яичницу". ) { Поставить сковородку на плиту. Включить плиту. Налить масла. Установить таймер на 1 минуту с активацией триггера "Сковорода разогрета". }; ( Получена команда "приготовить яичницу". Сковорода разогрета. ) { Разбить яйца. Посолить. Накрыть крышкой. Установить таймер на 5 минут с активацией триггера "Яичница готова". }; ( Получена команда "приготовить яичницу". Яичница готова. ) { Выключить плиту. }; Процесс обучения завершен. Далее готовая программа запускается командой например "Приготовь яичницу" в диалоговом окне. Подразумевается, что система узнает (была обучена ранее, таким же образом) эту команду и при ее получении активирует триггер "Получена команда 'приготовить яичницу'". Т.к. первая ситуация состоит всего из одного триггера, то она выполняется, а дальше по цепочке, через промежутки времени в 1мин и 5 мин выполняются и другие две. Можно добавить, что конкретно в этом примере два из 3х триггеров активируются посредством таймера, но в других случаях они могли бы активироваться на основании других процессов. Так, например, если готовность мы определяем не строго пятиминутным интервалом, а по изображению с камеры, то в этом случае уже превышение некоего порогового уровня белого активировало бы триггер "Яичница готова" и все равно вызывался бы обработчик третей ситуации. Также нужно обратить внимание, что и триггеры и ситуации иерархичны. Т.е. любая ситуация занимает некий уровень в дереве ситуаций и может иметь как вышестоящий узел, так и подчиненные. В данном примере вторая и третья ситуации вложены в первую. То же справедливо и для триггеров. Получена команда "приготовить яичницу". Сковорода разогрета. Яичница готова. Можете подумать почему.. В данном примере каждая ситуация содержат ненаглядно маленькое число триггеров: 2я и 3я по два, а первая вообще один. Но число триггеров может быть и большим. С увеличением глубины вложенности ситуации, количество триггеров, от которых она зависит, растет. Вот более наглядный пример (из предыдущих постов): Началась игра Текущая игра - игра в карты Соперник сделал ход картой Масть карты - такая-то Соответственно в диалоговом окне, в процессе обучения игре в карты, эту ситуацию нужно будет описать так: ( Началась игра. Текущая игра - игра в карты. Соперник сделал ход картой. Масть карты - такая-то. ) { Побить карту соперника. } Надеюсь так будет понятнее, что я имел в виду под ситуационным подходом к программированию. [Ответ][Цитата]
NO. Сообщений: 10700	На: Поиск новых идей - пути выхода из кризиса Добавлено: 23 апр 16 8:37 Есть много языков, где уже синтаксически всё в виде списков ситуация-реакция. Пролог, Erlang, ML, haskel. И иерархий там полно, они все рекурсивные. [Ответ][Цитата]
r Сообщений: 837	На: Поиск новых идей - пути выхода из кризиса Добавлено: 23 апр 16 9:30 Цитата: Автор: NO. Есть много языков, где уже синтаксически всё в виде списков ситуация-реакция. Пролог, Erlang, ML, haskel. И иерархий там полно, они все рекурсивные. Если они яйца жарить не умеют, то такое не подходит. [Ответ][Цитата]
гость 78.25.123.*	На: Поиск новых идей - пути выхода из кризиса Добавлено: 24 апр 16 1:50 r> ситуационный подход к программированию > Из комбинации триггеров (состояний ит событий) можно составить условие (ситуацию) это все очень хорошо. Действия как преобразователи ситуаций. кажется только не очень оправданным некоторый перекос внимания к системе действий в ущерб рассмотрению общей архитектуры системы, способной совершать 'осмысленные' действия. Cкажем, cистема обучена 'жарить яичницу', как было описано вами выше. Cистема получает соотв. команду. Чего явно не достает? Уровня общего мониторинга за 'глобальной' ситуацией. На плите УЖЕ стоит яичница, остывшая, правда. В данной глобальной ситуации 'приготовь яичницу' будет означать 'подогрей яичницу', а не сделай ее заново. [Ответ][Цитата]
NO. Сообщений: 10700	На: Поиск новых идей - пути выхода из кризиса Добавлено: 24 апр 16 2:31 Конечно умный обстоятельства использует, а не борется с ними. Видит возможности и частично сложившиеся образы. Все равно в итоге нужна последовательность действий, её построение это планирование. Лучше изучать на примере игр. Если противник пытается помешать пожарить яичницу начинается самое интересное. Есть Rete чтобы собрать условия в одно. В глубоких сетях есть и вспомогательные сущности и действия и связи через слои. [Ответ][Цитата]
r Сообщений: 837	На: Поиск новых идей - пути выхода из кризиса Добавлено: 24 апр 16 4:12 Изменено: 24 апр 16 4:25 Цитата: Автор: гость кажется только не очень оправданным некоторый перекос внимания к системе действий в ущерб рассмотрению общей архитектуры системы, способной совершать 'осмысленные' действия. Cкажем, cистема обучена 'жарить яичницу', как было описано вами выше. Cистема получает соотв. команду. Чего явно не достает? Уровня общего мониторинга за 'глобальной' ситуацией. На плите УЖЕ стоит яичница, остывшая, правда. В данной глобальной ситуации 'приготовь яичницу' будет означать 'подогрей яичницу', а не сделай ее заново. В диалоге на предыдущей странице речь велась о примитивной машине, возможно об несколько ином способе программирования робота, более похожим на обучение, более удобном что ли. Но все же именно человек прописывает все действия, которые должна выполнить машина в той или иной ситуации, Т.е. и позаботиться о подогреве, если сковородка уже стоит на плите нетронутая с прошлого раза, тоже должен человек. В том плане, что при обучении нужно заложить такую ситуацию и правильно ее обработать, если не подогреть сразу, то хотя бы уточнить, что делать с уже приготовленной. Т.е. если не хватает какой-то ситуации в системе, она добавляется человеком. Почему так? Потому что, система в которой машина сама заполняла бы обработчики ситуаций гораздо сложнее. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Поиск новых идей - пути выхода из кризиса Добавлено: 24 апр 16 21:57 Изменено: 24 апр 16 21:58 Цитата: Автор: r Потому что система, в которой машина сама заполняла бы обработчики ситуаций, гораздо сложнее. Для чего нужны подобные программы? Дело в том, что для того, чтобы компьютер/робот/программа смогли бы сами себя программировать, то есть, сами внутри самих же себя создавать сложные алгоритмы, которые было бы нестрашно передать на исполнение, так вот, для того, чтобы они могли это делать, для этого им нужен еще один промежуточный уровень - им нужен Язык описания алгоритмов. То есть, сначала, когда у них будет возникать какая-нибудь Задача, то они "решают" её в уме, придумывают, как бы её можно было решить. Затем они описывают эту, как бы уже "решенную" ими Задачу, на Языке описания алгоритмов, и если она описывается (а не каждая Задача, как мы знаем, поддаётся алгоритмизации), то это описание спускается вниз, на исполнительный уровень, где из него создается уже реальная Программа готовая к исполнению. Генерировать же куски кода непосредственно, например, случайным образом, либо перебором - я не представлю возможным, так как будет получаться много "мусора". Вот поэтому и нужен этот промежуточный уровень - Язык описания алгоритмов. И для начала его следует обкатать на диалоге с Человеком. Если Человек в диалоге с машиной сможет объяснить ей свой, придуманный им, Алгоритм, и машина создаст по этому его описанию действующую программу, которую можно будет запускать на исполнение БЕЗ ОТЛАДКИ (а процесс отладки программы - это более сложное действие, чем даже её создание, и компьютерам, я считаю, до этого уровня еще далеко), то тогда можно будет считать, что и сам компьютер/робот/программа сможет это сделать. И там останется лишь уже готовое найденное ими Решение перевести на Язык описания алгоритмов, а дальше - будет легче, так как к этому времени мы уже протестируем на простеньких программках эту часть диалога - процесс перевода алгоритма с Языка описания алгоритмов в действующий код. Таким образом, последовательность шагов будет такая: Задача -> Решение -> Описание алгоритма -> Программа (код) -> Исполнение Интеллект (для тех, кто спрашивает) прячется в связке "Задача - Решение", но без всей остальной части, то есть, без создания на базе этого найденного Решения хорошего грамотного Алгоритма, и без вывода его на Исполнители, мы этого Интеллекта не увидим, и не поймем, что он есть. Правда, появляется соблазн отбросить всю эту исполнительную часть, пусть, дескать, наш Интеллект выдаёт нам своё найденное им Решение (чего он там придумал), а мы уж сами будем решать, годится оно нам или нет, и сами будем переводить его в действующие Алгоритмы, если захотим. Но проблема тут заключается в том, что любой Интеллект без этой - исполнительной - обратной связи, и не Интеллект вовсе, и если даже он и будет генерировать Решения, то все они будут полностью оторванными от реальности, и не будут иметь никакого практического смысла. Даже элементарно - просто для того, чтобы вести осмысленный диалог с Человеком, и то - программе нужны будут исполнительные органы, то есть, опять же, все тот же алгоритмический исполнительный блок. То есть, что? Получается, что и тут - без этого промежуточного уровня - Языка описания алгоритмов - не обойтись. [Ответ][Цитата]
r Сообщений: 837	На: Поиск новых идей - пути выхода из кризиса Добавлено: 25 апр 16 9:45 Цитата: Автор: Vpolevoj Задача -> Решение -> Описание алгоритма -> Программа (код) -> Исполнение Есть идеи как на практике реализовать первую тройку из цепочки? Как формально описать задачу, решение и алгоритм? Посредством каких составляющих? [Ответ][Цитата]
Luarvik. Сообщений: 17287	На: Поиск новых идей - пути выхода из кризиса Добавлено: 25 апр 16 9:53 Изменено: 25 апр 16 9:57 Цитата: Автор:r Есть идеи как на практике реализовать первую тройку из цепочки? Как формально описать задачу, решение и алгоритм? Посредством каких составляющих? Самое смешное во всем этом то, что у животных тоже есть свои задачи, свои решения и алгоритмы, которые они сами же и исполняют, но при этом как-то совсем благополучно обходятся без описаний и... не перестают быть интеллектуальными [Ответ][Цитата]
Стр.38 (60): 1  ...  34  35  36  37  [38]  39  40  41  42  ...  60 << < Пред. | След. > >>