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

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

Все темы | Новая тема  Стр.37 (60) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: Нейрон
victorst Сообщений: 821	На: Нейрон Добавлено: 19 апр 16 1:34 Изменено: 19 апр 16 1:37 Людиии. Нравится биться насмерть с ветряными мельницами? Ну вы заглядывайте хоть изредка в старинные манускрипты типа М.Минский."Фреймы для представления знаний". По всему интернету эта книга раскидана. Хотя и сам Минский позже признает неполноценность его подхода, но отвергать его все же не следует. Что-то в этом есть. [Ответ][Цитата]
victorst Сообщений: 821	На: Нейрон Добавлено: 19 апр 16 2:08 Изменено: 19 апр 16 2:11 Думаю, через какое-то время дойдете до онтологического представления мира, ситуаций и общения, которое во многом является развитием фреймового подхода. Языки представления онтологий Там можете заодно глянуть про реификацию. Я довольно давно занимался онтологией верхнего уровня и созданием языка AIGL, основанного на ней. На нем можно было и программировать и общаться на произвольные темы роботам и людям (после определенного обучения). Ведь и Эсперанто нужно изучать, чтобы можно было им пользоваться. [Ответ][Цитата]
r Сообщений: 837	На: Нейрон Добавлено: 19 апр 16 9:52 Цитата: Автор: ignat99 Да используйте любой язык. Есть шаблоны (типа хвостовой рекурсии или сортировки хипа бинарным деревом) и их программисты и используют. А иногда вообще на уровне подключения готовой библиотеки а дальше write/read. Так же точно как в физике, можно любую какую угодно сложную систему сделать, а если надо будет измерять параметры - всё равно всё сведётся к измерению температуры (да же когда спектр расщеплённый глазами оцениваете - цвет это и есть температура возбуждения). То что описано это относиться к парадигме сентенциального программирования. Тут скорее комбинация, постановка ситуаций во главу угла это ситуационный подход, а коммуникация на базе естественного языка - интенциональный, ну и если хотите сентенциональный тоже. Однако же я не особо понял при чем тут шаблоны и рекурсия, когда стоит задача запрограммировать поведение машины объяснением и коммуникацией, без доступа к коду. Пока что вокруг нас нет роботов, потому не всем может быть понятна будущая проблема. Речь не о СИИ, и даже не об ИИ, а об обучении машин неограниченному количеству новых функций на базе ограниченного интерфейсного набора. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Нейрон Добавлено: 19 апр 16 10:28 Цитата: Автор: r ... стоит задача запрограммировать поведение машины объяснением и коммуникацией, без доступа к коду. Речь ... об обучении машин неограниченному количеству новых функций на базе ограниченного интерфейсного набора. r, давайте сделаем такую программу. Отведем на неё, скажем, месяц, если за месяц ничего не получится, то - отложим. Тут ведь что нужно. Разработать Универсальную структуру алгоритма (то, что вы называете парадигмой). Минимальный интерфейс, который позволяет человеку работать с этим Универсальным алгоритмом. И возможность постепенно наращивать определения, вплоть до использования слов из естественного языка. Задачи, на которых можно будет обкатать эти алгоритмы, следует выбрать попроще, например, классические строковые, типа, найти буквы в сообщении, подсчитать, заменить, удалить (пробелы и пр.), разрезать на части и пр. Я понимаю, что это очень простые задачи, но дело ведь не в них, а в том, КАК они должны быть запрограммированы - через человеко-машинный интерфейс, то есть, через диалог. Если мы сумеем это сделать, то принципиальная возможность решения подобных задач будет доказана. Ну, как, есть желание попробовать? [Ответ][Цитата]
r Сообщений: 837	На: Нейрон Добавлено: 19 апр 16 13:06 Изменено: 19 апр 16 13:11 Цитата: Автор: Vpolevoj Согласен. Нужен своего рода "переводчик". С обычного "человеческого" языка на формализованный компьютерно-программный. Насколько я понимаю ваше "ситуационное программирование" как раз и пытается заполнить эту нишу. Наверное, можно сказать и так. Цитата: Автор: Vpolevoj Да, человек думает "ситуациями". Но он так же думает и "ифами" (условиями), и "циклами". Иначе все эти конструкции не возникли бы в нашем языке (да и в программировании тоже). А так же он думает "событиями", и "функциями" (например, иногда склонен тупо следовать инструкциям). Думает, да. Но условие это часть ситуации, а элементарная ситуация и есть условие (иф). И циклами думает. Но не стоит придавать такое внимание циклам и ветвлениям, как это делается в программировании. Их нужно прятать от посторонних глаз. Цитата: Автор: Vpolevoj Описывая ситуацию, мы обозначаем сразу несколько "ифов", а рекомендуя выполнить действия в этой ситуации, мы тоже не обходимся без "ифов". И это - поддерживается нашим естественным языком. Если у нас ранее описана ситуация, то с добавлением ифа создается новая (как бы вложенная) ситуация. Цитата: Автор: Vpolevoj Вот, к примеру, как эта ситуация описывается на простом "естественном" языке. Предположим, что мы и есть тот самый человек, который в данный момент разговаривает с машиной, и пытается объяснить ей, что нужно делать, когда идёт дождь. ЕСЛИ ты собираешься выйти из дома [на улицу]{ Посмотри погоду [например, выгляни в окно, или запроси прогноз]}; Я в скобках пишу слова и фразы, которые могут быть опущены, но при этом подразумеваются. Мы исходим из того, что наша система уже в достаточной степени умная, чтобы уметь восстанавливать скрытый смысл из контекста. Далее. ЕСЛИ [на улице] идёт дождь{ Возьми зонтик}; И у нас получаются две ситуации (причем, одна из них вложена в другую), и обе описываются конструкцией ЕСЛИ. То есть, у тебя, хотя ты и говоришь, что избавляешься от циклов и ветвлений, не пропадает сама эта конструкция ЕСЛИ, а объяснить программе на простом человеческом языке, что значит ЕСЛИ то-то и то-то, много труднее, чем задать ей линейные инструкции выполнения чего бы то ни было. То есть, сказать программе, делай это, потом это, а потом вот это - много проще, чем один раз объяснить ей, что значит ЕСЛИ. Если, конечно, это условие (и, разумеется, переменная, которой касается это условие) уже не будет содержатся внутри самой этой программы. То есть, я хочу сказать, что попытка объяснить программе, что значит "идёт дождь" может стать очень трудным делом для "простого человека", а скажем, сказать ей, что когда у тебя вот эта переменная (лампочка, или датчик, или индикатор) становится "ИСТИНА", то это означает, к примеру, что "идёт дождь", и тогда делай то-то и то-то. Я предлагаю не то чтобы избавится от ифа (ЕСЛИ) и цикла (ПОКА), а спрятать их внутри. Про вложенность ситуаций все верно, практически все жизненные ситуации есть вложенные, но мы можем гулять по их уровням, вниз-вверх. Рассмотрим игру в карты. Мы хотим объяснить машине какими картами можно бить карты противника. Это ситуация с множеством вложенностей. Во-первых это ситуация ("началась игра"), во-вторых это уже составная ситуация ("началась игра", "текущая игра - игра в карты"), в-третьих это ("началась игра", "текущая игра - игра в карты", "сейчас - ход соперника"), в-четвертых это ("началась игра", "текущая игра - игра в карты", "сейчас - ход соперника", "соперник сделал ход картой"), в-пятых это ("началась игра", "текущая игра - игра в карты", "сейчас - ход соперника", "соперник сделал ход картой", "масть карты - такая-то") и т.д. Все это многоуровневая структура. Но ее описание теоретически можно сделать неявным, на основе контекста. Объяснять что такое ЕСЛИ не надо, я говорил, что это все не СИИ, а инструмент для обучения ИИ, так что можно расслабиться. Речь о том, чтобы внутреннее состояние маскировать и надстраивать над ним новые уровни. Так, переменную со значением от датчика влажности выше пороговых 95% можно вывести наружу как ситуацию "возможно идёт дождь", а у системы, обладающей зрением может быть и более точная ситуация - "идёт дождь". Чтобы человек уже работал с символическими именами ситуаций, а не с именами переменных. Цитата: Автор: Vpolevoj То есть, еще раз, я хочу сказать, что трудность перевода с человеческого языка на машинный заключается вовсе не в циклах и ветвлениях, человеку думать в этих категориях вовсе не трудно, а, я бы даже сказал, наоборот, привычно и удобно, а в невозможности, зачастую, передать машине с помощью одного лишь словесного описания той самой СИТУАЦИИ, о которой ты говоришь. Инструкции же (то есть, сами действия) передать с помощью слов можно. Передача описания может происходить на основе базовых ситуаций, уже понятных системе. Цитата: Автор: Vpolevoj Я обычно иллюстрирую эту ситуацию следующим примером (например, когда объяснял основы программирования своим студентам). Я даю им классическую (с точки зрения обучения программирования) задачу - научить робота (программу), как следует жарить яичницу. Типичные приколы, типа, "[взять и] разбить два яйца" я опускаю, посолить и поставить на плиту [не включив её] - тоже. Доходим до места, где требуется завершить процедуру. Девушки обычно говорят: "Жарить до готовности". А я их спрашиваю: "Откуда робот [программа] знает, когда наступает эта самая "готовность"?" Вот тебе типичная "ситуация". Попробуй описать её в своих терминах. Допустим, что всему остальному ты своего робота [программу] уже научил. Сковородка на огне, масло на сковородке, яйца разбиты правильно (скорлупы в яичнице нет), посолил (сколько надо), идёт процесс приготовления. Сколько нужно держать яйца на сковородке? Как ты определишь это состояние? Ответ будет зависеть от технической оснащенности такой системы. Если она обладает машинным зрением, то наверняка сможет определить средний уровень белого цвета в сковородке. При превышении уровня порогового значения белого цвета может возникнуть ситуация "готовности". Как система определит этот пороговый уровень это уже другой вопрос, но и он решаем. Например можно показать ей фото готовой яичницы, она подсчитает средний уровень белого цвета на фото и примет его за эталон. Для теста (мучного изделия) это будет уровень желтого. Цитата: Автор: Vpolevoj Вот. И это хорошо, что ты это понимаешь. Но человеку все же проще и удобнее мыслить и объяснять машине [программе] свою задачу в тех терминах и теми конструкциями языка, к которым он привык, то есть, и условиями, и циклами, и ситуациями, и инструкциями (алгоритмами) тоже - кому как удобнее. Это уже программа должна переводить этот "словесный бред", в какой бы форме он ни был высказан, в свою, понятную только ей, жесткую и формализованную структуру. А обучать этому простых пользователей, и тем более, заставлять их принудительно мыслить теми же категориями, я считаю, глупо и не нужно. Я и предлагаю выбросить наружу в интерфейс/протокол/язык взаимодействия знакомые человеку понятия а не имена переменных на латинице. Цитата: Автор: Vpolevoj Люди - не машины. Хотя, они и машины тоже. Но вот думают они отнюдь не алгоритмически, во всяком случае, не строго. И на одну и ту же ситуацию у них может быть сразу несколько вариантов действий, включая, например, и такое: "А мне так захотелось!", или "Я решил сегодня попробовать вот так!", или "А-а-а - была, не была!". Робот это помошник, пусть он делает дело, а такие конструкции оставим людям. Цитата: Автор: Vpolevoj Да, циклы зачастую носят неявный характер. Типа "Посмотри на полках" - содержит в себе неявный цикл. Или "третий поворот налево" - означает, что нужно отсчитывать повороты налево, и на третьем повернуть - тоже цикл. И т.д. А о чем это нам говорит? Да все о том же - о том, что люди мыслят циклами (в том числе). Кроме того, в человеческой деятельности встречается довольно много рутинного однообразного труда основанного на циклах, в том числе и на бесконечных. Работа на конвейере, например. Сельскохозяйственная деятельность. И т.д. А это накладывает свой отпечаток и на речь и на мышление тоже. Так что, мы - люди - мыслим циклами, и говорим, кстати, тоже. Ситуации вполне покрывают циклы. Цитата: Автор: Vpolevoj Эта мысль мне тоже понятна. Должен существовать некий базовый набор ситуаций и методов, из которых, как из кубиков, можно будет развить и построить любой алгоритм. Именно. Цитата: Автор: Vpolevoj И, насколько я понял, парадигма Ситуационно-ориентированного программирования сильно перекликается с так называемым Автоматным программированием. Сходство есть, но автомат не может отклониться от жесткого набора промежуточных состояний. Ситуативная модель призвана расширять функционал, строить абстрактные многоуровневые иерархии. Теоретически.. Цитата: Автор: Vpolevoj А я думаю, что очень даже пересекается. Мало того, то что ты делаешь, оно напрямую связано с обслуживанием диалоговой системы, так как подразумевает под собой наличие интерфейса ("переводчика") с человеческого языка на язык машинного алгоритма. И при этом совершенно не важно, какие именно задачи призвана решать сама эта программа, даже если в её обязанности входит всего лишь поддержание самого этого диалога. Ну собственно да, сам диалог может быть заранее описан тысячами ситуаций. Цитата: Автор: Vpolevoj PS У меня, кстати, совсем другой подход к формализации описания алгоритма, и он, как мне думается, более приближен именно к человеческому языку и способу мышления. Можешь рассказать вкратце? В этом деле очень важна степень формализации. Важно чтобы это можно было закодировать. [Ответ][Цитата]
r Сообщений: 837	На: Нейрон +1 Добавлено: 19 апр 16 13:30 Цитата: Автор: victorst Людиии. Нравится биться насмерть с ветряными мельницами? Ну вы заглядывайте хоть изредка в старинные манускрипты типа М.Минский."Фреймы для представления знаний". По всему интернету эта книга раскидана. Хотя и сам Минский позже признает неполноценность его подхода, но отвергать его все же не следует. Что-то в этом есть. Никто ни с кем не бьется. Фрейм это модель явления, если фрейм объекта то это список его свойств, логично, что фрейм ситуации это список условий ее наступления. То, что кто-то это назвал фреймом не так уж и важно. Обычная структура из программирования, или запись базы данных это тоже фрейм. Ничего гениального Минский не изобрел. Я тоже не говорю ничего того, чего не знал бы каждый (даже никаких Минских никому читать не надо), просто пытаюсь структурировать и систематизировать то, что попадает в область внимания. [Ответ][Цитата]
r Сообщений: 837	На: Нейрон Добавлено: 19 апр 16 13:51 Цитата: Автор: Vpolevoj r, давайте сделаем такую программу. Отведем на неё, скажем, месяц, если за месяц ничего не получится, то - отложим. Тут ведь что нужно. Разработать Универсальную структуру алгоритма (то, что вы называете парадигмой). Минимальный интерфейс, который позволяет человеку работать с этим Универсальным алгоритмом. И возможность постепенно наращивать определения, вплоть до использования слов из естественного языка. Задачи, на которых можно будет обкатать эти алгоритмы, следует выбрать попроще, например, классические строковые, типа, найти буквы в сообщении, подсчитать, заменить, удалить (пробелы и пр.), разрезать на части и пр. Я понимаю, что это очень простые задачи, но дело ведь не в них, а в том, КАК они должны быть запрограммированы - через человеко-машинный интерфейс, то есть, через диалог. Если мы сумеем это сделать, то принципиальная возможность решения подобных задач будет доказана. Ну, как, есть желание попробовать? Желание есть, но видение у нас может быть разное, как и языки разработки. За месяц не получится. Я работал над такой программой считай все прошлое лето и даже до половины не добрался. Сейчас приходится опять ходить на роботу и времени уже ни на что нет к сожалению. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Нейрон Добавлено: 19 апр 16 14:25 Изменено: 20 апр 16 7:41 Цитата: Автор: r Цитата: Автор: Vpolevoj PS У меня, кстати, совсем другой подход к формализации описания алгоритма, и он, как мне думается, более приближен именно к человеческому языку и способу мышления. Можешь рассказать вкратце? В этом деле очень важна степень формализации. Важно чтобы это можно было закодировать. Если совсем вкратце... ... то я представляю любой алгоритм (всю программу, и каждую процедуру) в виде бесконечного цикла с двумя условиями - одно на входе (типа, While) и одно на выходе (типа, Until). Внутри этого бесконечного цикла спрятано тело - исполняемая процедура, которая представлена структурой case (с N ветвями). Оба условия в этой конструкции важные и обязательные: первое проверяет и обеспечивает вхождение в цикл, второе - завершение процедуры и выход из цикла. Вместо любого условия, если оно не требуется, можно поставить логическую единицу, и тогда эта конструкция превращается в обычный цикл While или Until, по желанию, либо в структуру case (если оба условия выключены), либо просто в обычную процедуру (если вдобавок к выключенным условиям и у case N будет равно 1). И я считаю, что с помощью подобной конструкции можно представить практически любой алгоритм, любой степени сложности, так как вместо вызова исполняемой процедуры (внутри блока case) можно поместить ссылку (вызов) на еще одну точно такую же конструкцию - и за счет этого можно наращивать сложность алгоритма до какой угодно степени, при этом не теряя структурную простоту и понимание работы каждой из вызываемых процедур в отдельности. Кроме того, для каждого составленного таким образом алгоритма требуется всего ОДИН универсальный обработчик, который, к тому же, не так уж и трудно написать. Все эти блоки, на мой взгляд, довольно легко формализуются, укладываются в удобную структуру и могут быть представлены, например, в виде одной записи в какой-нибудь БД. Таким образом получается, что практически любой алгоритм можно представить как набор строк в специализированной Базе Данных. Если присваивать этим, таким образом составленным, алгоритмам имена, то можно вызывать их в других алгоритмах, обращаясь к ним уже по именам. Если же вместо некоторых имен использовать СЛОВА, то получится что-то вроде алгоритмического языка, где по какому-нибудь СЛОВУ запускается целая процедура, которая может обслуживать довольно сложные процессы и т.д. Получается, что данный подход к описанию алгоритмов обладает свойством наращивания, начиная от простейших функций и операций и заканчивая сложными обработчиками очень сложных ситуаций с большим количеством условий и ветвлений, и все это можно заложить в компьютер, общаясь с программой на Естественном Языке (ну, почти, так как придется ограничивать себя лишь теми словами, которые уже определены, но при этом ничто не мешает доопределить любое количество нужных тебе слов, и пользоваться уже ими). [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Нейрон Добавлено: 20 апр 16 5:35 Изменено: 20 апр 16 7:34 Немного подробностей и примеров. Возьмем эту схему. На самом деле, она не полная, но, я так думаю, что любой, кто возьмется что-то по ней делать, довольно быстро и легко её "усовершенствует" и доведет но нужных кондиций. Поэтому, я не буду на этом останавливаться. Выделю лишь то, что я сам считаю в ней главным. И для начала, обратите внимание на то, что весь алгоритм, и основной внутренний блок в теле цикла, обрамляют вспомогательные процедуры (блоки 1, 3, 5, 7). Зачем они нужны? Тем более, что они, вроде бы, не входят в смысловую часть схемы алгоритма, а просто тупо добавляют количество линейно расположенных последовательных блоков. Тогда - для чего они? Но, на самом деле, все эти блоки несут свою очень важную возложенную на них функцию, они предваряют и завершают каждый - свою часть процедуры. Это - своего рода Конструкторы и Деструкторы, которые есть в ООП. То есть, в первом блоке, к примеру, условно, конечно, происходит выделение памяти, запрашивание необходимых системных ресурсов, подключение внешних устройств, установление связи, если требуется и т.д., и инициализация переменных. А в последнем - все наоборот: удаление переменных, разрыв связи, отключение внешних устройств, освобождение системных ресурсов и выделенной памяти. Если же это не программа, а - какое-то внешнее "человеческое" событие, то там - всё тоже самое. Перед началом каких-то действий, всегда требуется к ним подготовиться, а это делает в моей схеме первый блок, а после завершения всей работы, нужно за собой "прибрать" - и этим занимается последний блок в моей схеме. То же самое относится и к двум "обрамляющим" блокам (3 и 5) внутри тела цикла. Первый из них подготавливает выполнение тела - основного действия функции, а последний - завершает, подытоживает это действие, скажем, фиксирует получившийся результат (например, записывает во временный файл, или в переменную). Посмотрим теперь на условия (входное и выходное). И если последний блок сравнения по смыслу сопоставим с таким же выходным блоком в классическом представлении (Until), и служит для определения достижения результата и конца выполнения процедуры, то первый входной блок, хотя он и идентичен такому же в классической схемотехнике (While), но в данном конкретном случае он несет немного другую смысловую нагрузку. Он проверяет достаточность необходимых условий для выполнения операции, её, так сказать, возможность. Приведу пример. Допустим, у нас есть модем (программно реализованный), и нам нужно с его помощью передать сообщение на другой модем. Описываем это действие с помощью моей схемы. Инициацию (Конструктор) и отключение (Деструктор) я опускаю, поскольку сейчас не об этом речь, перейду сразу к блокам сравнения. Так вот, первый блок сравнения (который в классическом представлении аналогичен While) проверяет в данном случае, как я уже говорил, возможность осуществления операции, скажем, наличие соединения, далее, если соединение есть, то модем пересылает часть сообщения на другой модем (очередную порцию), а после этого смотрит, все ли порции сообщения уже отправлены (выходной блок Until), и если еще не все (не конец процедуры), то отправляет наверх, на повтор. Там опять смотрится, есть ли соединение, и так далее... Вы, наверное, скажете, а есть ли в этом смысл? Можно же, например, установить соединение (проверив его), а потом переслать всё сообщение целиком, пачка за пачкой, и лишь в конце, после отправки всего сообщения, проверить, не разорвалась ли связь. И, если разорвалась, то - повторить всю процедуру сначала. Но представьте себе, что это у нас не модем, и что между входным блоком проверки (While) и выходным (Until) проходит довольно много времени, и происходит довольно большое число событий, то в этом случае, как мне кажется, такая проверка вовсе не будет излишней. Тем более, что её всегда можно обойти, если необходимость в ней и в самом деле отсутствует (а для этого нужно просто-напросто записать в условие проверки логическую единицу). А теперь примеры. Можно ли с помощью этой схемы Универсального алгоритма описать, скажем, пример с зонтиком? Можно. Почему бы и нет. Хотя этот алгоритм предназначен для более сложных случаев, а не для такой, в общем-то достаточно примитивной связи "условие -> действие". Но я, все же, опишу. Значит, условие (которое r называет "ситуацией") - "Идет дождь" и "Собираемся выйти на улицу". Его можно запихнуть в первый блок проверки моей схемы (While). Причем, можно сделать это условие вложенным, поместив один Универсальный алгоритм в другой, с каждым из этих условий по отдельности, а можно и совместить (правильно, зачем "городить огород", если эти два условия, на самом деле, сцепленные), и записать их так: "Если идёт дождь, а ты собираешься выйти из дома", через связку И, разумеется. А далее в основном блоке (case) применяется всего одно правило: "Возьми зонт". Более правильно, конечно же, будет разбить эту схему на две - одна должна быть вложена в другую: желание выйти из дома - это внешний цикл, проверка на дождь - внутренний, и там и там результатом будет ВЫХОД из дома, просто в одном случае - с зонтом, а в другом - без. Эту схему легко можно реализовать с помощью моего Универсального алгоритма, но я не буду этого делать в виду явной очевидности этого. Более сложным, на мой взгляд, является пример с "приготовлением яичницы". Но и тут, если разобраться, всё встает на свои места. Так, первый блок (Конструктор) берет на себя функцию подготовки. В него входит: яйца (само собой), масло, соль, сковорода, и наличие работающей и исправной плиты (с газом, если эта плита газовая, или с электричеством, если плита электрическая, с горячим углями, или огнём, если это печка и т.д. - не буду углубляться). Первый блок проверки (While), таким образом, проверяет наличие всего этого и готовность к осуществлению самого действия, а также (хочу обратить на это ваше особое внимание), состояние или текущий этап, на котором находится реализация нашего плана (в этом заключается еще одно принципиальное отличие моего Универсального алгоритма - его особенность, если хотите). И если этот блок проверки говорит, что все нормально, то выполняем сами действия. Какие? А вот тут нам и пригождается блок ветвления (case). Для осуществления последовательных процедур, если реализация плана подразумевает разбиение его на отдельные этапы, можно все эти действия разбить на части и пронумеровать их. И тогда в блоке case можно выполнять эти действия по очереди, в зависимости от того, на каком именно этапе реализации своего плана мы находимся. В деле "приготовления яичницы" можно выделить следующие этапы: 1) Поставить сковороду на [разогретую и работающую] плиту, положить [полить] на неё немного масла, разбить туда несколько яиц [требуемое количество], посолить; Я объединил несколько различных действий в один пункт, хотя этого делать не следовало бы, но в данном случае я просто не хочу загромождать описание алгоритма. Просто это всё делается ОДИН раз, и поэтому их можно, в принципе, и объединить. 2) Непосредственно жарка (приготовление) - так как это длительный процесс. Поэтому, в блоке case, если мы находимся на первом - начальном - этапе, то мы проделываем все необходимые действия, которые, как я уже сказал, нужно сделать всего один раз, проверяем, не готова ли наша яичница (а она не готова), и возвращаемся к началу. Когда же мы входим в наш бесконечный цикл во второй (и более) раз, то мы уже окажемся в блоке case на другой ветке (под номером 2), а там происходит процесс "приготовления". Как же это делается? Да еще с помощью бесконечного цикла? А для этого (для "приготовления яичницы") мы выбираем какой-нибудь безопасный для нас интервал времени (я предлагаю выбрать для нас рабочий интервал в 10-15 секунд, так как за это время с яичницой ничего не произойдет, даже если огонь будет очень сильным, за минуту, к примеру, если наша яичница уже начала пригорать, может многое измениться, и у неё образуется очень неприятная горькая на вкус корочка снизу, так что, интервал времени не должен быть очень большим, но при этом вовсе не обязательно делать его слишком маленьким). И мы "жарим яичницу" (по ветке номер 2 в блоке case) 10-15 секунд, после чего проверяем, не готова ли яичница, и если не готова, то все возвращаем назад, к началу. А там, кстати, снова производится проверка на готовность, только не самой яичницы, а - условий для её приготовления. Зачем, - спросите вы? А мало ли что... Огонь потух, электричество пропало, сковородка упала, одно яйцо оказалось тухлым... и т.д. Так что, возврат в основной цикл будет возможен только в том случае, если есть для этого возможность, в противном случае вся процедура будет аварийно прекращена. Итак, мы "жарим" свою "яичницу" интервалами по 10-15 секунд, постоянно проверяя, не готова ли она. А теперь, внимание, вопрос, что называется, на засыпку: КАК ИМЕННО МЫ ПРОВЕРЯЕМ её готовность? И, главное, где? Вы скажете, конечно же, что в блоке проверки (Until), где же еще? А я вам скажу, что нет, что это не так. В блоке Until действительно делается проверка, вот только этот блок не может (не умеет) выполнять сложные действия - он всего лишь навсего сравнивает, возникла ли уже логическая единица в целевой (для её функции) переменной или еще нет. А где же тогда устанавливается сама эта переменная? Вот! А устанавливается она (в какое-то конкретное значение) в блоке, который завершает структуру case. А это, если вы видите, самый обычный процедурный блок. Вот в нём-то и происходит процедура определения "готовности яичницы", по цвету ли, по запаху, по твердости ли сворачиваемого белка, либо по совокупности всех этих признаков - это уже не важно, для нас важно лишь то, что именно в нём некая логическая переменная, которая потом будет проверяться в блоке Until, приобретает своё значение. Вот, собственно и всё. Как видите, процедура может закончиться двояко: либо по готовности, либо аварийно. И да, в конце всей этой процедуры необходимо будет "прибрать за собой" - выполнить блок Деструктор. Вот теперь, действительно, всё. [Ответ][Цитата]
NO. Сообщений: 10700	На: Нейрон Добавлено: 20 апр 16 5:57 Ну и как таблицу таких штуковин научить жарить яичницу? [Ответ][Цитата]
victorst Сообщений: 821	На: Поиск новых идей - пути выхода из кризиса Добавлено: 20 апр 16 8:40 Изменено: 20 апр 16 8:48 Языки описания доменов и задач планирования Почти у всех планировщиков имеется проблема замкнутости мира. Но это лучше чем ничего. Робот самостоятельно научился готовить блинчики [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Поиск новых идей - пути выхода из кризиса Добавлено: 20 апр 16 11:41 Изменено: 20 апр 16 11:51 Цитата: Автор: victorst Языки описания доменов и задач планирования Почти у всех планировщиков имеется проблема замкнутости мира. Но это лучше чем ничего. Робот самостоятельно научился готовить блинчики Виктор, спасибо тебе за приведенную тобой ссылку (сам понимаешь, не трудно прочитать материал, трудно его найти). Я - прочитал. Заодно просмотрел всё, что там есть, на этом сайте. Жалко, что человек бросил заниматься этим делом, но... не он первый, не он последний. А теперь по поводу приведенной тобой статьи. Хотел сначала по пунктам разложить, даже начал конспектировать, но потом понял, что всё напрасно, так как суть не в этом. Там, действительно, все крутится вокруг "замкнутого мира". Но это, насколько я понимаю, так поставлены условия задачи. Даже по приведенным примерам это видно. Там, например, есть робот, который находится в замкнутом помещении, состоящем из нескольких комнат, между которыми есть [или нет] двери, внутри этих комнат может стоять мебель, например, шкаф, который в эксперименте может заменить куб, или стул, который заменяет другой куб, или ящик, есть также выключатели на стенах, которые включают/выключают свет в комнатах, либо другие электроприборы, и т.д. Вот в этом, целиком определенном условиями эксперимента, мире и следует осуществлять операции по планированию своих действий этому роботу. Поэтому - все логично и понятно. И то, как можно заметить, даже в таком, полностью описанном и детерминированном мире, осуществлять операции планирования очень и очень непросто. И чем более сложным мы делаем этот "замкнутый" мир, тем сложнее становится в нем ориентироваться и планировать свои действия. А теперь - критика. Программирование (а планирование - это вид программирования), которое отталкивается от ситуации (как это предлагает делать r), становится невозможным, так как описание любой ситуации должно включать в себя ВСЕ переменные ВСЕХ объектов рассматриваемого в модели, даже "замкнутого" мира. И любое изменение любой из этих переменных будет означать новую ситуацию. А если мы хотим, чтобы хотя бы часть из этих переменных в некоторых случаях не учитывалась (а в других бы наоборот - учитывалась), то такая задача превращается в нечто вроде "гадания на кофейной гуще". Если же мы будем подходить строго, и будем требовать от описания своего мира полной определенности каждой из доступных нам переменных (детерминированности), то такой мир, в своем описании, очень быстро разрастается до неимоверных размеров, и просто перестает соответствовать реальности - поскольку реальность зачастую НЕ детерминирована. Если же мы, к тому же, выпустим в это пространство не одного, а сразу нескольких роботов, и, допустим, они не будут уведомлять друг друга о совершенных ими действиях, то жить в таком "замкнутом" мире, а тем более, ПЛАНИРОВАТЬ хоть что-то, они попросту не смогут. А люди, кстати, с такой ситуацией прекрасно справляются. К тому же, у людей не "закрытый", а "открытый" мир. Но - не суть. Суть же этой проблемы - в данном случае, планирования - на мой взгляд, заключается в том, что они, как и всегда, впрочем, пытаются решить задачи, которыми в нашей психике занимается СВЕРХСОЗНАНИЕ, на уровне СОЗНАНИЯ, то есть, путем описания свойств и при помощи формальной логики. Но оно так НЕ РЕШАЕТСЯ. Понимаешь? Эта задача в такой постановке и теми средствами не решаема, в принципе не решаема. Но она решается, и вполне успешно, если выйти за предложенные ими рамки. Причем, можно разрешить эту тупиковую ситуацию сразу несколькими способами, в зависимости от поставленной задачи. К примеру, я могу с помощью своей Я-центрической модели произвести описание практически любого объекта, и осуществлять [умственные] операции с ними, причем, пользуясь при этом стандартными однотипными операциями. Можно воспользоваться для описания Мира (открытого, заметь) Субъект-Субъектными отношениями, и тогда добавление нового Объекта (читай, нового Субъекта) в Модель не будет представлять никакой сложности, так как эта процедура будет входить в стандартный набор процедур для операций с Субъектами. И т.д. То есть, попытка формализовать описание Мира (даже "замкнутого", что уж там говорить об "открытом") всегда заканчивается провалом. Потому что сам подход, с ОБЪЕКТИВНОЙ точки зрения - оказывается тупиковым. И я считаю, что причина тут вовсе не в слабости наших представлений о Мире, а просто Мир не такой. Он не укладывается в формализованную схему этих наших представлений о нём. Вот поэтому все подобные попытки, даже ограниченные описанием "замкнутого" мира, обречены на провал. Как только мы попытаемся усложнить этот свой мир (даже не открыть его - нет), так тут же он выйдет у нас из под контроля. И осуществлять в нём операции планирования станет попросту невозможно. Вот так. А вывод? А вывод будет такой. Нужно научиться описывать мир ДРУГИМИ средствами (например, пользуясь субъективной точкой зрения), и планировать свои действия в мире исходя из условий НЕОПРЕДЕЛЕННОСТИ (части, или даже всех) его параметров. И тогда нам будет ВСЁ РАВНО, что там на что повлияло, или кто-то без нас взял и изменил какой-то параметр - ну и что. Мы и без того не очень-то на это рассчитывали - пришли и исправили, и поставили все так, как надо. И планируем свои действия мы уже не исходя из конкретной ситуации (ситуация в этом плане лишь может либо облегчить, либо затруднить реализацию нашего плана), а отталкиваясь от своей Цели, и из сущностных свойств имеющихся под рукой объектов. А в нужное состояние их можно перевести принудительно, если, конечно, никто не будет мешать. =========== PS Чуть не забыл. Робот, который в ролике печет блины, на самом деле печь блины не умеет, ему же не скажешь, сходи на кухню, напеки немного блинов на завтрак - он не поймет. А то, что он поддевает на лопатку и переворачивает блин - так в этом и заключается все его умение, именно на этом и сконцентрировали свое внимание его разработчики - на обучении робота сложным (с их точки зрения) движениям - "с учителем". Что на это скажешь? Молодцы. Хотя движения этого робота выглядят несколько неуклюжими. Вот, к примеру, робот, который играет в настольный теннис - тот действительно производит впечатление. [Ответ][Цитата]
victorst Сообщений: 821	На: Поиск новых идей - пути выхода из кризиса Добавлено: 20 апр 16 13:37 Изменено: 20 апр 16 13:47 Классы в онтологиях в отличие от ООП могут представлять неполное описание мира. Это позволяет расширять классы в процессе работы ИИ. Т.е. онтологичесое описание подходит для незамкнутого мира и основано на точной математической модели. Если взять, к примеру, OWL DL, то здесь гарантировано, что интеллектуальный агент выполнит логический вывод за ограниченное время. Реификация (материализация, овеществление утверждений) С помощью реификации можно выражать субъективные суждения (свои и чужие), хранить их, и использовать в процессе функционирования ИИ включая общение. [Ответ][Цитата]
r Сообщений: 837	На: Нейрон Добавлено: 20 апр 16 15:14 Цитата: Автор: Vpolevoj Значит, условие (которое r называет "ситуацией") - "Идет дождь" и "Собираемся выйти на улицу". Его можно запихнуть в первый блок проверки моей схемы (While). Причем, можно сделать это условие вложенным, поместив один Универсальный алгоритм в другой, с каждым из этих условий по отдельности, а можно и совместить (правильно, зачем "городить огород", если эти два условия, на самом деле, сцепленные), и записать их так: "Если идёт дождь, а ты собираешься выйти из дома", через связку И, разумеется. Тут есть один непонятный момент. Кто будет запихивать? В том плане, что если это будет делать человек через коммуникацию, то ему придется указывать системе в какой именно блок нужно добавлять правила. А блоков таких могут быть тысячи. Если система сама будет добавлять, то ей тоже нужно знать куда именно. Т.е. в обоих случаях нужно как-то адресовать изменяемые блоки. Допустим, если процесс программирования будет идти через диалог, и нужно будет в блок, описывающий ситуацию "(идет дождь, мы выходим на улицу)->Взять зонт" добавить новое ограничение, скажем такое "(идет дождь, мы выходим на улицу, для передвижения будет использоваться личный автомобиль)->зонт не брать". Тут получается второе условие является вложенным в первое, т.к. оно покрывает только часть первого. Таким образом в случаях, когда планируется передвижение пешком, или на общественном транспорте, система воспользуется рекомендацией из более общего первого правила и возьмет зонт, а в случае использования личного транспорта, воспользуется рекомендацией из более частного второго условия и не возьмет. Как планируется определять в какие блоки добавлять эти рекомендации? [Ответ][Цитата]
r Сообщений: 837	На: Поиск новых идей - пути выхода из кризиса Добавлено: 20 апр 16 16:03 Изменено: 20 апр 16 16:05 Цитата: Автор: victorst Языки описания доменов и задач планирования Автор статьи указывает на две нерешенные проблемы так называемого ситуационного исчисления: проблема косвенных эффектов и проблемы ограничительных условий. Первая из них заключается в том, что очень сложно описать все эффекты действия: "Так, например, перемещение шкафа роботом из одной комнаты в другую повлечет за собой перемещение и всех книг внутри шкафа, и освобождение места в комнате, и изменение внешнего вида комнаты, и многие другие изменения." Но не понятно, почему автор выделяет такую сложную процедуру, как перемещение шкафа, состоящую из сотни элементарных действий, как одно действие. Я писал раньше, что система должна оперировать простейшими действиями, меняющими всего одно свойство объектов мира за раз, для таких действий кол-во эффектов действия будет равно 1. И уже из таких простейших действий должна собираться цепочка. Суть второй проблемы состоит в том, что очень трудно перечислить все условия, которые могут препятствовать выполнению действия: "Например, пусть робот должен выполнить действие переместить шкаф из северного угла комнаты в южный. Выполнению такой задачи может препятствовать множество вещей..." Опять же, попытка свалить все в кучу, привести сложный процесс к одному действию. Хотя на самом деле это несколько уровней абстракции, в каждом из которых должны быть спрятаны свои ограничения, и они не будут видны вышестоящему уровню. Начальный уровень это движение всего одного сочленение манипулятора, у него свое окружение (параметры, ограничения, эффекты и т.д.) Следующий уровень это позиционирование захвата манипулятора в конкретную точку пространства - работа нескольких сочленений манипулятора. Тут свое окружение. Следующий уровень - управление всеми манипуляторами - передвижение самого робота в конкретную точку пространства, управление равновесием при передвижении и подъеме груза. Тут свое окружение. На этом этапе нужно учитывать тяжесть шкафа, но только на этом уровне, а не на всех. Следующий уровень - обработка изображения, чтобы знать в какую конкретно точку пространства нужно спозиционировать сначала самого робота, а потом и все его захваты. Следующий уровень - передвижение шкафа на маленькое расстояние с предварительным расчетом его траектории, прогнозированием и контролем столкновений с другими предметами. Тут свое окружение. Вот уже тут придется учитывать конфигурацию и расположение как самого шкафа, так и остальной мебели. И только на следующем уровне можно рассматривать полное передвижение шкафа, как одно действие, но для этого уровня уже и не осталось тех проблемных ограничивающих условий, о которых писал автор, т.к. все они обрабатываются на нижних уровнях. А для этого уровня разве что ограничивающим фактором является лень - лучше оставить шкаф в покое и пойти попить пивка. Со сложностью мира природа борется приближением точности, иерархией, адаптивными фильтрами. Никто не запрещает использовать эти методы и в ИИ. [Ответ][Цитата]
Стр.37 (60): 1  ...  33  34  35  36  [37]  38  39  40  41  ...  60 << < Пред. | След. > >>