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

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

Все темы | Новая тема  Стр.22 (27) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: Программирование поведения робота без доступа к коду
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 8:43 Изменено: 08 окт 16 8:59 Цитата: Автор: Vpolevoj Не знаю, видишь ли ты, но ситуация складывается прямо противоположная относительно базовой концепции КА: здесь нет реакции на текущее состояние, а есть желание ПОЛУЧИТЬ требуемое состояние, при этом изначально не известно, как это можно сделать. Вижу, мы это как-то обсуждали. Собственно, я ж чего две темы и создал. Я тогда предложил ввести таблицу фактов для каждого действия, фактов которые он изменяет. Правда мне слово "действие" не очень нравится, оно ассоциируется с каким-то механическим движением, хотя процесс может быть чисто умственным - операции исключительно со внутренней моделью, внешне никак не выражаемые. Тут наверно больше подходит слово метод. Дело в том, что автоматную парадигму можно объединить с решением задач, когда система пытается достигнуть определенного состояния. Допустим поставленная задача будет разбиваться на подзадачи отдельной подсистемой. В идеале (мне так кажется) одна задача - это один метод для ее решения. Подсистема строит одну или несколько цепочек таких подзадач. Каждая цепочка позволяет достигнуть цели, но разными методами. Система выбирает какую-то цепочку и пытается ее выполнить. Последовательно выполняет метод для каждой подзадачи в цепочке с контролем результата. Поскольку при построении цепочки у системы точно будет информация по предполагаемому состоянию мира после каждой подзадачи (а иначе такую цепочку не построить), то можно после каждого выполненного метода сверять получившееся состояние с ожидаемым. Если совпадает, то выполняется следующий метод, если нет - создается новая задача по исправлению сложившегося расхождения. А дальнейшее выполнение текущей цепочки откладывается. Так вот, реализация методов (их внутрянка) как раз может состоять из наборов автоматных условий. Ну и, так как метод внутри тоже может состоять из методов, то и автоматические программы для подсознания тоже могут быть уже готовыми, то есть на автоматах. И автоматы сначала придется составлять человеку, так как, чтобы заработал верхний уровень (решатель задач), нужен запас готовых методов, а чтобы система могла создать свой первый метод сама (стала обучаемой) нужен работающий решатель задач. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 9:10 Изменено: 11 окт 16 1:12 Цитата: Автор: r Вернемся к сбору роботом ягод. Допустим упрощенный алгоритм сбора будет иметь следующий цикл действий: A. выбрать ягоду B. сорвать выбранную ягоду C. отправить сорванную ягоду в емкость То есть алгоритм графически можно представить в виде кольца: Предположим в алгоритм необходимо внести дополнение, учитывающее качество ягоды. Допустим, если ягода оценена зрительной подсистемой как хорошая, то она отправляется в емкость, если как плохая - выбрасывается на землю. Вот что получилось в результате: Это простенький пример, где в каждом условии только одна предпосылка, но их может быть несколько. Не знаю получится ли тогда такие алгоритмы изображать графически. r, обычно принято рисовать программы КА в виде графов (примерно так, как это сделал ты), и для небольших программ, тем более таких, в которых количество состояний известно заранее и оно не слишком большое, я считаю это вполне допустимым. Но в более общем случае, мне думается, удобнее пользоваться примерно такой схемой связей между модулями, которую ты приводил чуть выше. Чем она удобнее? В первую очередь тем, что она вносит в общую схему возможность декомпозиции - выделяет в ней отдельные блоки, структурируя их по уровням, и мы можем произвольно фиксировать внимание на той или иной части этой схемы (что облегчает наше восприятие, а следовательно и понимание и контроль). Причем, общий алгоритм анализа работы всей системы остается неизменным (это нам обеспечивает подход программирования в стиле КА). То есть, переходя от всей схемы к её отдельным участкам (и наоборот) мы не меняем принципы анализа и восприятия (а это важно). Что бы еще можно было добавить в это представление, для того, чтобы сделать его еще удобнее и нагляднее? Вот, смотри. Что мы имеем? Состояние. Обработку (этого состояния). И новое состояние (в которое система переходит после этой обработки). Как это можно было бы отобразить? Например, так. Что мы тут видим? Сверху указывается, какое событие (состояние) обрабатывается (его номер). Затем указывается обработчик. И внизу указывается номер состояния, в которое система переводится после выполнения этого обработчика (иногда этих состояний может быть несколько, поэтому под подвал требуется чуть больше места, отсюда и треугольник в последней моей версии). И тогда твой пример можно перерисовать так. Из этой схемы видно, что в состоянии 1 вызывается обработчик В, который переводит систему в состояние 2, и т.д. При этом полный граф переходов рисовать вовсе не требуется (для его визуального представления), так как, какая нам, в конце-концов, разница, по кругу идут эти переходы или не по кругу (по циклу). Нам важно лишь то, что мы видим, что все состояния обрабатываются (и система полная). Далее, предположим, что мы ввели еще какие-то состояния и написали для них свои обработчики. Что изменится и как это можно отобразить? Из этой схемы видно, кстати, что после того как ягода сорвана - состояние 2 (из состояния 1 - ягода выбрана, и совершенного действия В - сорвать ягоду, система переходит в состояние 2 - ягода сорвана), происходит её проверка (действие D - анализ сорванной ягоды), а результатом этого действия могут быть сразу ДВА состояния системы: 4 и 5, что соответствует плохой и хорошей ягоде. Для каждого из этих состояний нужно запрограммировать своё особое действие (что мы и видим в этой схеме). Состояние 4 (ягода хорошая) вызывает обработчик С (положить ягоду в корзину), а состояние 5 (ягода плохая) вызывает обработчик E (выбросить эту ягоду). Но ты после этих двух разных действий указываешь тоже ДВА разных состояния системы (3, и 6 соответственно), и на каждый из этих состояний указываешь один тот же обработчик - А (выбрать ягоду), которая приводит систему в одно и то же состояние 1 (ягода выбрана). И это ЯВНО ИЗБЫТОЧНО. Требуется (и напрашивается) упрощение. Здесь операция D (анализ сорванной ягоды) может приводить систему в одно из двух возможных состояний (4 и 5), а действия вызванные этими состояниями (выбросить плохую ягоду или положить хорошую ягоду в корзинку) приводят систему в одно и то же состояние 3 - (система свободна и требуется выбрать новую ягоду - совершить действие А). Что я и отобразил на своей схеме. Как видишь, такое представление задачи даже проще и гораздо удобнее для анализа и внесения дополнений. Тем более, что, как я уже говорил, оно допускает декомпозицию, и любое из указанных на этой схеме ДЕЙСТВИЙ тоже можно представить в точно таком же виде: в виде условий (состояний) и реакций на них, просто, уровнем ниже. [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 10:27 Изменено: 08 окт 16 10:58 Ок, неплохо получилось. Но шестой узел выбрасывать нельзя. Сейчас объясню почему. Если рассматривать схему в привязке к коду (для большей наглядности), то видим, что в условии 5 выполняется метод "выбросить сорванную ягоду". И, чтобы алгоритм сразу перешел в условие 3, нужно чтобы метод "выбросить сорванную ягоду" активировал триггер "ягода отправлена в емкость", что неправильно. условие 5 ( ягода оценена как плохая ) { выбросить сорванную ягоду } условие 3 ( ягода отправлена в емкость ) { выбрать ягоду } Тут какое дело, для машины, методам, по сути, названия не нужны, это для себя мы различаем их по названию: "выбросить сорванную ягоду", "отправить ягоду в емкость", представляя при этом образ падания ягоды на землю в первом случае и попадания ее в корзину во втором. Машина может уникально идентифицировать методы не по называниям (и не по уникальным ID, как можно было бы подумать, так как от это пользы 0), а по набору фактов которые метод меняет. Согласен, в обычной программе для компьютера, узел 6 был бы лишний, но мы же хотим, чтобы машина, в конечном итоге, сама создавала факты, для новой информации. Представим такую космическую ситуацию, что робот понимает то, что он видит, как человек. Понимает в том смысле, что когда он впервые в жизни увидит (например случайно промазав), как ягода падает не в корзину а на землю, то он автоматически создаст факт (опять же без имени) для этого случая, так как для случая падания ягоды в корзину у него уже есть факт, и он явно не подходит. И под этот факт он создаст отдельный метод, так как тот который есть не подходит тем, что результат его выполнения оказался (случайно) другим. Это я все к тому, что у такого умного робота метод условно называемый нами "выбросить сорванную ягоду" будет менять именно соответствующий этому методу триггер (факт), поэтому такая избыточность тут будет нормой. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 10:48 Изменено: 08 окт 16 11:01 Цитата: Автор: r Дело в том, что автоматную парадигму можно объединить с решением задач, когда система пытается достигнуть определенного состояния. ... так как, чтобы заработал верхний уровень (решатель задач), нужен запас готовых методов, ... а чтобы система могла создать свой первый метод сама (стала обучаемой) нужен работающий решатель задач. Вот я и предлагаю подумать над "решателем задач", попробовать понять, что же это такое. Можно, конечно, ввести такое понятие, как "требуемое состояние триггера". И отталкиваясь от него, сформировать такие понятия как "требуемые условия" и "требуемые состояния" (в том числе и "ожидаемые условия" и "ожидаемые состояния"). И после этого начать рассматривать эти "требуемые" и "ожидаемые" состояния как реально действующие для описания общего состояния системы (как это делаешь ты). И тогда, вроде бы, всё должно получиться, правда, у меня до конца в этом уверенности нет. Потому что, опять же, здесь важно не то, какие условия мы рассматриваем (мнимые или реальные), а то, ОТКУДА программа (робот) будет брать эти "требуемые состояния" (имеется ввиду, что будут возникать новые "требуемые состояния", а ведь именно для них нам нужно составить новую программу)? Эта же самая проблема действует и на человека. Как я уже говорил, когда человек решает какую-нибудь задачу, то от того, насколько хорошо и четко он представляет себе "конечный результат", который требуется получить в итоге, он и будет решать эту свою задачу - успешно или не очень. То есть, чем четче представления о том, что требуется получить, тем проще найти решение, и тем компактнее оно будет. Это же относится и к роботу. Другими словами, я считаю, что наша проблема сводится не столько к поиску механизмов программирования, сколько к тому, чтобы научить робота вычленять главное от неглавного в формировании "картины будущего", и если он научится это делать, то свести потом это к комплексу автоматных действий, я думаю, будет можно. Но только ПОСЛЕ того, а не ДО. Попробую немного порассуждать на эту тему. Допустим, у нас есть уже готовое "требуемое состояние". Что из этого может следовать? Во-первых, система должна проверить текущее состояние на соответствие требуемым, и если всё будет совпадать (кроме состояния незначимых триггеров, которые можно игнорировать), то делать ничего не нужно - итак все хорошо (но это, так сказать, тривиальное решение). Во-вторых, текущее состояние может отличаться от "требуемого" состоянием какого-то одного триггера, и в системе есть действие, которое его меняет. Тогда вполне очевидно, что может быть вызвано это действие, и вполне реально ожидать, что требуемые условия будут в результате этого действия достигнуты. Пример. Мы пришли домой поздно, и в квартире, естественно, темно (а требуется, чтобы было светло). И мы знаем, что для того, чтобы в квартире появился свет, нужно его включить. Щелкаем выключателем, и - ву-аля - да будет свет! (Всё остальное совпадает.) В-третьих, эти состояния могут быть разделены двумя-тремя и т.д. шагами. Скажем, мы щелкнули выключателем, а свет в квартире так и не зажегся. Что делать? Проверить пробки. Заменить сгоревшую лампочку. И т.д. То есть, мы просто ввели несколько промежуточных действий между "щелкнуть выключателем" и "да будет свет". Но все равно - все понятно. В-четвертых, таких несовпадающих триггеров может быть несколько, но в этом случае задача будет сводиться к набору последовательных/параллельных задач по приведению этих триггеров в требуемое состояние. В-пятых (и это уже сложнее), когда мы не можем привести триггер (или группу триггеров) сразу в требуемое состояние, и нам для этого нужно приложить и усилия, и терпение. Такие задачи решаются через итерации (то есть, путем организации бесконечного цикла). И я считаю этот подход самым универсальным. Когда мы запускаем какое-нибудь действие на повтор, время от времени проверяя, насколько изменились текущие условия (насколько они стали ближе к требуемым). Так организована, к примеру, ходьба, учеба, готовка пищи, уборка помещения, распиливание дерева, и т.д. и т.д. Это когда мы делаем что-то, постепенно и последовательно приближая себя к конечному результату. Этот же подход позволяет подобрать то или иное действие, которое теоретически способно привести к решению. Если бесконечное повторение какого-нибудь действия не приводит к значительным сдвигам в текущей ситуации, то следовательно, нужно сменить это действие, и выбрать что-то другое. А в целом, здесь действует правило: "Если долго мучиться, то что-нибудь получится!" [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 11:04 Изменено: 08 окт 16 11:31 Цитата: Автор: r Ок, неплохо получилось. Но шестой узел выбрасывать нельзя. Сейчас объясню почему. Если рассматривать схему в привязке к коду (для большей наглядности), то видим, что в условии 5 выполняется метод "выбросить сорванную ягоду". И, чтобы алгоритм сразу перешел в условие 3, нужно чтобы метод "выбросить сорванную ягоду" активировал триггер "ягода отправлена в емкость", что неправильно. условие 5 ( ягода оценена как плохая ) { выбросить сорванную ягоду } условие 3 ( ягода отправлена в емкость ) { выбрать ягоду } У тебя просто неправильно описано условие 3: нужно не "3 - ягода оправлена в емкость", а - "3 - робот свободен и готов действовать". Тогда всё встает на свои места. И не забывай внизу (своего кода) указывать явно, в какое состояние приводит систему то или иное действие (можешь это делать, к примеру, в квадратных скобочках). Так будет проще и понятнее. условие 5 ( ягода оценена как плохая ) { выбросить сорванную ягоду } [3] условие 3 ( робот свободен и готов действовать ) { выбрать ягоду } [1] условие 2 ( ягода сорвана ) { проверить ягоду } [4]V[5] [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 12:05 Ок, так нормально, еще как вариант "манипулятор свободен". На этом показательном примере возникает вопрос, как машина узнает, что именно этот флаг нужно взводить в обоих методах, когда код уже будет создаваться не человеком. [Ответ][Цитата]
NO. Сообщений: 10700	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 12:26 Параллельные программы трудно отлаживать, там случаются ситуации, которые трудно воспроизвести. Поэтому такое редко используют. А если и делают, то пишут транслятор в С, а оттуда все равно в код. Посмотрите как пишут скрипты для игрушек. И есть специально для роботов, даже у Микрософта был Robotics Studio, а экспериментальных наверно сколько угодно. Смешно же смотреть как взрослые люди рассуждают о том, как ягодку сорвать. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду +1 Добавлено: 08 окт 16 12:32 Цитата: Автор: r Ок, так нормально, еще как вариант "манипулятор свободен"... ... и "готов к использованию". Так как, "свободен", еще не значит, что уже можно переходить к следующей фазе. Для состояния 3 требуется оценка двух триггеров: "манипулятор свободен" (скажем, ягода выброшена) и система "готова к работе" (то есть, все в порядке, ничего выходящего за привычные рамки нет, можно продолжать). Цитата: Автор: r На этом показательном примере возникает вопрос, как машина узнает, что именно этот флаг нужно взводить в обоих методах, когда код уже будет создаваться не человеком. Поэтому я и предлагаю двигаться от конца (а не от начала), то есть, отталкиваться от того, КАКОЕ СОСТОЯНИЕ нам нужно получить. Есть внешние триггеры (которые от нас не зависят, мы можем лишь совершать те или иные действия, в своем стремлении их изменить), а есть триггеры внутренние (которые от нас зависят), но их состояние нам тоже нужно устанавливать через выполнение тех или иных действий. То есть, робот ДОЛЖЕН ЗНАТЬ, какие именно флаги и каких именно триггеров он будет менять, осталось лишь подобрать те действия, которые позволят ему это сделать. В данном случае системе (роботу) НУЖНО получить состояние, чтобы продолжать свою работу (либо положить сорванную ягоду в корзину, либо выбросить её). То есть, нужно исходить не из того, что делать с сорванной уже ягодой, а с получением "требуемого состояния", через то или иное действие. Например, сорвали ягоду, а она оказалась плохая, а продолжать работу все равно нужно (значит, нужно перевести систему в состояние готовности), и как это можно сделать - например, "выбросить эту ягоду". Выбросили ягоду - освободили манипулятор - система готова к работе - установили нужный триггер. Понимаешь, не что делать в той или иной ситуации, и не какой триггер установить после уже сделанного действия, а - наоборот - нам нужно, чтобы были установлены те или иные триггеры (так называемый "признак конца"), и мы знаем (на некоторые из них), что для этого нужно сделать, делаем это, после чего устанавливаем требуемые нам триггеры (если, конечно, действия были успешными, но это уже другие условия, и другие обработчики). А фактически - это другой стиль программирования (который нам еще предстоит выработать). [Ответ][Цитата]
NO. Сообщений: 10700	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 12:59 Чтобы робот сам планировал действия ему нужно предоставить то, что называют "теория". Описание ресурсов, их свойств, состояний, операций, событий. Потом указываем, что нам нужна полная ягод корзина. Ничего не говорим как этого добиться. Он используя теорию строит вывод. Как для теоремы строится доказательство. Сводит её к аксиомам, в данном случае к элементарным, изначально бессмысленным действиям и проверкам. https://ru.wikipedia.org/wiki/Соответствие_Карри_—_Ховарда сигнатура функции является теоремой, то есть если что-то реализуемо, то тип функции это доказуемая формула [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 15:04 Изменено: 08 окт 16 15:07 Цитата: Автор: Vpolevoj Понимаешь, не что делать в той или иной ситуации, и не какой триггер установить после уже сделанного действия, а - наоборот - нам нужно, чтобы были установлены те или иные триггеры (так называемый "признак конца"), и мы знаем (на некоторые из них), что для этого нужно сделать, делаем это, после чего устанавливаем требуемые нам триггеры (если, конечно, действия были успешными, но это уже другие условия, и другие обработчики). А фактически - это другой стиль программирования (который нам еще предстоит выработать). Идея здравая, надо обдумать. Тогда уже готовый код будет полностью согласоваться с принципами создания алгоритма в решателе. О таких подходах я не слышал, может уже есть реализации? [Ответ][Цитата]
TimKruz Сообщений: 323	На: Программирование поведения робота без доступа к коду Добавлено: 08 окт 16 15:36 Цитата: И, следовательно, чем хуже, чем неадекватнее, чем беднее, чем схематичнее и т.д. будет эта модель, тем хуже будут ваши отношения, и тем быстрее они будут прекращены, ввиду "глупости", "штампов", "нечуткости", и пр. со стороны программы, так как человек просто устает от такого общения и ему "становится скучно", и он выходит из данных отношений - находит себе для этого другой объект. Речь ведь идёт не о дружеских или любовных, а о симбиотических отношениях с программой. Программа дополняет пользователя, пользователь дополняет программу. И вместе они решают определённые задачи, которые встают перед ними. Так что тут не может быть речи о том, что "пользователю стало скучно общаться с программой". Цитата: И чем дольше ты будешь упорствовать в отрицании этого факта, тем хуже у тебя будет получаться конечный результат. А вот если ты уделишь этому вопросу хотя бы толику своего внимания, то вполне может так статься, что ты выйдешь со своей программой на какой-нибудь НОВЫЙ УРОВЕНЬ, возможно, что и на тот, на который ты и сам не рассчитывал. Имхо, концентрироваться на "модели собеседника" - тупик в плане разработки широкого ИИ, потому что это не первопричина интеллекта, а его следствие, продукт. Программа должна уметь делать что угодно; создание модели собеседника - это одно из частных умений программы, результат её "интеллектуальной" деятельности. Т.е. описанный мною диалог юзера с ИИ - это всего лишь один из вариантов обучения этого ИИ. Он так поступает, потому что его этому научили. Его можно было обучить совершенно другим задачам, изменив реплики/коды, флаги и последовательности действий. И тогда он бы поддерживал не "модель собеседника", а уже какую-то другую "модель". Вот это - возможность научить ИИ чему угодно, в том числе поддержанию "модели собеседника" и связного диалога - и есть моя цель. Цитата: Параллельные программы трудно отлаживать, там случаются ситуации, которые трудно воспроизвести. Достаточно ограничить область памяти каждого потока и обмениваться с ними данными только во время синхронизации. Т.е. чтобы потоки были независимыми. Цитата: Чтобы робот сам планировал действия ему нужно предоставить то, что называют "теория". Описание ресурсов, их свойств, состояний, операций, событий. Потом указываем, что нам нужна полная ягод корзина. Ничего не говорим как этого добиться. Он используя теорию строит вывод. Посмотрел бы я, как ребёнок будет собирать ягоды в лесу, если он никогда не видел ни ягод, ни леса, но ему на словах объяснили, что это такое и что от него требуется. Даже если этот ребёнок смог бы выполнить эту задачу чисто по словесному описанию исходных и целевых состояний, в его голову пришлось бы запихнуть столько знаний, что просто пойти с ним в лес и показать, как и какие собирать ягоды - будет в миллион раз быстрее и проще. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 5:19 Изменено: 09 окт 16 6:03 Цитата: Автор: VPolevoj А фактически - это другой стиль программирования (который нам еще предстоит выработать). Цитата: Автор: r Идея здравая, надо обдумать. Тогда уже готовый код будет полностью согласоваться с принципами создания алгоритма в решателе. О таких подходах я не слышал, может уже есть реализации? Готовой реализации нет, есть лишь идеи, как это можно сделать. Я представляю себе всю процедуру программирования в этом стиле по типу ИНЬ-ЯН, когда два процесса проектирования (условно: сверху - от цели, и снизу - от готовых простейших блоков) сталкиваются в середине, где они сцепляются друг с другом, и получается одновременно как бы и готовое работающее решение, поскольку оно опирается на уже проверенные существующие блоки, и достижение именно того результата, который был запланирован изначально. Но пока, повторюсь, у меня это существует лишь в виде идеи, не более того. Можно обсудить (если хочешь). Интересно, для этого обсуждения ты будешь заводить отдельную ветку? Оно же не вписывается не в "программирование робота без доступа к коду", не в "планировщик задач", или вписывается? [Ответ][Цитата]
victorst Сообщений: 821	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 5:52 Мне представляется создание специального какого-то отдельного языка внутри ИИ для его программирования несколько надуманным. Этот подход похож на то, как создатели языка OWL внедрили в его конструкцию частности, то, что можно было бы выразить более универсальным языком. Взять к примеру, триггеры, которые могут принимать только два значения. А почему только два, а не три и не более? Может быть вообще триггеры должны отражать вероятность или уверенность? Или переменные. Какого они могут быть типа? Неужели первобытные люди, когда подсчитывали добычу, имели представление о целых и комплексных числах? [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 5:59 Изменено: 09 окт 16 6:15 Цитата: Автор: Vpolevoj Готовой реализации нет, есть лишь идеи, как это можно сделать. Я представляю себе всю процедуру программирования в этом стиле по типу ИНЬ-ЯН, когда два процесса проектирования (условно: сверху - от цели, и снизу - от готовых простейших блоков) сталкиваются в середине, где они сцепляются друг с другом, и получается одновременно как бы и готовое работающее решение, поскольку оно опирается на уже проверенные существующие блоки, и достижение именно того результата, который был запланирован изначально. Но пока, повторюсь, у меня это существует лишь в виде идеи, не более того. Можно обсудить (если хочешь). Как я понял, ты предложил готовые блоки тоже строить по принципу "от цели", но у меня с этим возникли трудности. Я попытался посмотреть на код своей змейки и прикинуть как он должен быть изменен, чтобы условия срабатывали не на текущую ситуацию, а для достижения требуемой ситуации. И застрял. То есть вроде понятно, какая должна быть разница между новым решением и существующим, но не понятно, как в таком случае все должно работать. Вот например у меня есть условие, которое срабатывает в момент, когда змейка уткнулась в границу поля. Обработчик этого условия меняет направление движения змейки. Это условие срабатывает на определенную ситуацию - дальше двигаться прямо невозможно, ну и как решение - поворачиваем. Как переделать условие так, чтобы оно срабатывало на достижение целевой ситуации? И какая это ситуация вообще? И самое главное нужно ли переделывать чтобы низкоуровневый код мог сам принимать решения? Ведь если мы делаем так, что условия срабатывают на достижение ситуации и у нас есть несколько условий, которые позволяют достичь одной и той же ситуации только разными методами, то интерпретатор сам выберет какой-то первый попавшийся метод. Цитата: Автор: Vpolevoj Интересно, для этого обсуждения ты будешь заводить отдельную ветку? Оно же не вписывается не в "программирование робота без доступа к коду", не в "планировщик задач", или вписывается? Наверное должно было быть разделение на программирование человеком (но с использованием такого подхода, который в перспектие позволит сделать надстройку для автоматического программирования поведения робота) и самопрограммирования по принципу разбиения задачи на множество подзадач. Две проблемы - две темы. А получилось какое-то кривое название у темы. Пусть все что то не по решателю будет тут, уже и так куча всего собралась. [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 09 окт 16 7:29 Изменено: 09 окт 16 7:44 Цитата: Автор: victorst Мне представляется создание специального какого-то отдельного языка внутри ИИ для его программирования несколько надуманным. Этот подход похож на то, как создатели языка OWL внедрили в его конструкцию частности, то, что можно было бы выразить более универсальным языком. Если мы допустим имеем решатель, который разбивает задачу на сотню мельчайших задач, где каждая задача решается выполнением элементарного метода, то возможно внутренний язык будет лишним. Мы сразу на заводе заливаем в робота весь набор методов, скажем на С++, и он только ими и оперирует. Но тогда вопрос как покупателю обучить робота новому методу. Вот детей в школе когда учат складывать в столбик, скажем трехзначные числа. Можно нарисовать на доске два числа, одно под другим и сказать - берем по очереди каждый столбик справа налево и складываем две цифры, если есть переполнение - добавляем единицу к столбику слева. Если не будет внутреннего языка, то как обучить робота новым эвристическим методам? Цитата: Автор: victorst Взять к примеру, триггеры, которые могут принимать только два значения. А почему только два, а не три и не более? Может быть вообще триггеры должны отражать вероятность или уверенность? Если использовать парный подход в определении триггеров, когда одну и ту же суть отражают два триггера, но один в утвердительной форме, а другой в отрицательной (с частицей "не"), то ситуация с неопределенностью значения чего либо решается одновременно деактивацией триггерной пары. Например если есть пара "кот шредингера жив" и "кот шредингера не жив", то до открытия ящика оба эти триггеры неактивны (что говорит о неопределенности), а после открытия - активируется один из них. А вот потребуются ли триггеры с большей разрядностью, чем 2, я не знаю, может быть для некоторых задач и потребуются. Цитата: Автор: victorst Или переменные. Какого они могут быть типа? Неужели первобытные люди, когда подсчитывали добычу, имели представление о целых и комплексных числах? Триггеры в большинстве случаев могут существовать и без переменных, особенно на верхних уровнях. Операции с числами можно производить и без переменных с числовым типом. Если представить число как список односимвольных разрядов и обрабатывать его в цикле, активируя например такие триггеры: - "текущий разряд является нулем" - "текущий разряд является единицей" - "текущий разряд является двойкой" и т.д. до девятки Ну и сложение типа такого: "текущий разряд в списке А является двойкой" + "текущий разряд в списке B является пятеркой" = "текущий разряд в списке С является семеркой". То есть по сути вычисления - символьные, а не числовые. Может наш мозг так и работает. Просто достает из памяти сумму для символов. Да медленно, но зато обходимся без int, float, double и пр. А таблица умножения. Мы же ее тоже заучиваем. [Ответ][Цитата]
Стр.22 (27): 1  ...  18  19  20  21  [22]  23  24  25  26  27 << < Пред. | След. > >>