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

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

Все темы | Новая тема  Стр.9 (27) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: МЫШЛЕНИЕ
NO. Сообщений: 10700	На: МЫШЛЕНИЕ Добавлено: 05 сен 16 9:37 и бывают "мысли вслух" [Ответ][Цитата]
TimKruz Сообщений: 323	На: Программирование поведения робота без доступа к коду Добавлено: 05 сен 16 13:08 Цитата: Потому что, бесконечно циркулирующие в памяти процессы, без возможности их завершения и вывода на исполнители, по меньшей мере, выглядят глупо, а в реальности могут привести к перегрузкам и зависанию всей программы (системы). С точки зрения прикладного программирования, такой "бесконечный" цикл можно вывести в отдельный от основного поток (thread) - тогда программа (интерфейс и основной код) будет функционировать даже если с этим циклом произойдёт что-то ужасное. При этом реализуется интерфейс взаимодействия этого потока с основным, чтобы его можно было при необходимости приостановить или "перенаправить в другое русло" (сменить задачу). Я вот задумался над введением такого цикла в своё интеллект-ядро, только придётся каким-то способом (пока не знаю, каким) реализовать "тормозящие" узлы ассоциативных цепочек (аналог "тормозящих нейронов"), чтобы система не выводила бесконечный поток данных на свой выход. Тогда она сможет более полно реагировать на раздражители и даже проявлять инициативу по прошествии времени, т.е. будет "думать" непрерывно. Цитата: когда 10-летний ребенок, который еще многого не видел и не понимает, но при этом легко болтает о чем угодно (хотя, я так думаю, он навряд ли способен отстаивать свою точку зрения, да и сформулировать её доступно тоже) Таких детей в интернете с каждым годом всё больше, и они отстаивают свои точки зрения... Акселерация, блин. Цитата: То есть, постепенно наращивая систему и её возможности, мы неизбежно расширяем и её словарный запас Мало приклеить к роботу моторчики. Нужно его научить ими управлять. То есть помимо собственно наращивания нужно активное обучение... Цитата: Как у них происходит переход от полного неумения и непонимания к освоению всех богатств нашего языка? ...методами подражания и экспериментирования. Ребёнок: 1. повторяет действия (движения, слова, интонацию) за окружающими людьми и 2. совершает "случайные" действия, чтобы проверить реакцию окружающих предметов на эти действия (можно сказать, он "исследует мир", хотя пока он не осознаёт, что он это делает). Постепенно подражание сходит на нет (тормозные нейроны подавляют сигналы зеркальных нейронов, когда они не нужны), а экспериментирование выходит на новый уровень за счёт накопившейся базы ассоциативных цепочек (действия уже не "случайны", а основаны на богатом жизненном опыте). Я это вижу так. Цитата: Но ты же в своих программах используешь отладочные процедуры и применяешь на этапе прогона тестовые задачи... тогда о чем ты говоришь? Почему мы "не можем залезть в голову" своей программы? И почему мы "не можем увидеть, что ощущает наша программа"? Мы можем сделать томограмму или энцефалограмму мозга и узнать, какие нейроны возбуждаются, когда человек что-то чувствует (видит, слышит), говорит или делает. Это аналогично отладочным функциям в программе. Но эти методы не позволяют нам (возможно, только пока) узнать, осознаёт и ощущает ли человек своё Я, как он ощущает мир и так далее. Мы можем только спросить человека "Как ты ощущаешь себя?" и получить субъективный ответ. Объективный ответ на этот вопрос не существует. Та же история и с программой - мы видим значения её переменных, видим, какие действия совершает процессор, но мы никак не можем прочувствовать то, что в данный момент чувствует программа. Только сама программа может рассказать нам, что и как она чувствует, но это, конечно же, не научные данные - программе верить в этом вопросе нельзя, как нельзя верить в том же вопросе по определению субъективному человеку. Цитата: Вот тот, кто ей управляет, тот на самом деле, и есть настоящий Субъект. Потому что именно он говорит Модели Мира, что важно, а что нет, на что стоит обращать внимание, а что можно смело выкинуть и забыть, какие задачи приоритетнее, сколько усилий следует прилагать для поиска решения и т.д. Что важно - определяется "моделью мира" по принципу "чему сильнее и дольше обучали, то и важнее" - т.е. если ребёнку сто раз сказали, что смотреть на светофор и машины важнее, чем пялиться в телефон - его "модель мира" будет требовать от него соблюдения ПДД в первую очередь, а только потом читать СМСки. Ну, это в моём понимании "модели мира", т.е. ключевой части нашей памяти. А если не она делает всё это, тогда кто? "Бессмертная душа" что ли? Цитата: В простейшем случае - это будет рекурсия. Это когда одна и та же функция вызывает саму себя, все время подставляя в качестве аргумента какие-то текущие значения. Это приемлемо, если такая функция, во-первых, всего одна, и во-вторых, она способна найти решение хотя бы при каких-то своих значениях. Тут важно лишь предусмотреть, чтобы не возникало ситуации с уходом в бесконечность (так называемая "дурная бесконечность") Реальная рекурсия не может уйти в бесконечность - быстро переполняется стек вызова. Тут нужна не рекурсия, а цикл. Рекурсия же используется для вычисления "фрактальных" формул, когда конец известен (т.е. возникает ситуация, когда функция больше не вызывает себя, а возвращает результат - "спираль раскручивается", возвращаясь в точку самого первого вызова этой функции). Цитата: Третий путь, как мне кажется, более интересный. Он подразумевает под собой связь из трех функций, замкнутых в цикл. Одна из этих функций все время уточняет ВХОД - входные данные, вторая занята обработкой, а третья - оценкой найденного решения, и выводом на исполнители, если такое решение уже найдено. Если же решения еще нет, то - весь цикл повторяется. Функций можно сделать хоть мильён, а можно вообще без функций. Это детали конкретного кода. Разрабатывая алгоритм, не нужно вести подсчёт, сколько и каких функций использовать. Нужно продумать последовательность действий, которые должен выполнить исполнитель (компьютер), чтобы достичь результата. Разбивать на функции будем потом. Цитата: порождая подчас не совсем традиционные и не вполне предсказуемые решения А вот это плохо. Базовый алгоритм должен быть строго предсказуем, чтобы в нём не скрывались фундаментальные ошибки. А вот база данных может быть построена как угодно. [Ответ][Цитата]
r Сообщений: 837	На: Программирование поведения робота без доступа к коду Добавлено: 07 сен 16 15:16 Изменено: 07 сен 16 16:05 Цитата: Автор: Vpolevoj Я и сам хотел задать подобный вопрос, но TimKruz меня опередил. Правда, я хотел задать вопрос не только о том, как выходить из этого "замкнутого цикла", но и о том, как его организовать, что он из себя представляет (желательно, с примерами). Я не имел в виду стандартный цикл в программистском понимании - некую плоскую последовательность вызовов функций. Я имел в виду цикл как нечто большее - "живой ансамбль" из постоянно реактивирующихся фактов в сочетании с как бы "объемной" совокупностью обработчиков, выполняющихся по возможности параллельно. Давайте рассмотрим пример с малым кольцом, как более простой, но вместе с тем и менее "живой", если можно так сказать. Как бы мы описали стандартный простенький цикл на обычном языке: int i=1; int n=20; while (i<n) { do something i=i+1; } Этот цикл как бы блокирует поток, выполняющий его, вплоть до выхода из цикла. Теперь, как можно было бы создать цикл без явного описания цикла, то есть через факты и правила. Тут дело касается внутренностей моей разработки потому на время вернусь к терминам триггер и условие. Допустим есть все те же две переменные i и n. Отличие заключается в том, что для переменной i создаются два триггера: первый срабатывает (активируется) на изменение значения переменной i (и деактивируется после того, как все обработчики условий, в которых участвует этот триггер, будут выполнены), а второй активен всегда, когда значение i меньше значения n. Допустим, в систему загружается условие ниже, после чего переменной n присваивается значение 20, а переменной i значение 1. условие ( значение i изменилось значение i меньше значения n ) { do something i=i+1; } n=20 i=1 По умолчанию значение i равно None (Null). Так что присвоение ей значения 1 активирует сразу оба триггера и условие выполнится. Выполнение инструкции увеличения i на единицу внутри условия снова активирует триггер "значение i изменилось", а так как триггер "значение i меньше значения n" все еще активен, то условие выполнится опять. И так 19 раз. Это все работает конечно гораздо медленнее, но это пока не важно. Интересной особенностью такого подхода есть то, что поток блокируется не на все 19 итераций, а только на одну. Каждый раз после выполнения обработчика какого либо условия, производится анализ измененных обработчиком переменных и активация соответствующих триггеров. А эти новые активированные триггеры могут активировать новые условия. Плюс триггеры могут активироваться из-вне (по входам от датчиков и пр.) и активировать свои условия. И обработчики будут выполняться как бы параллельно, но в одном потоке, на одном ядре процессора. Не знаю, понятно ли объяснил. Другими словами, если завести еще переменные j и m, аналогичные переменным i и n, создать для них такие же триггеры и такое же условие, то оба цикла будут выполняться параллельно. Вот вам и "кольцо", в котором параллельно выполняются цепочки "мыслительных потоков". Потому на этой схеме и показаны два блока со встречными стрелками. Левый блок символизирует выполнение обработчика (правила) для конкретной ситуации (условия, набора триггеров), а правый блок символизирует активацию выполняемым обработчиком новых (до этого неактивных) триггеров (фактов), что приводит к вызову обработчиков других условий. И так по кругу. Цитата: Автор: Vpolevoj Потому что, бесконечно циркулирующие в памяти процессы, без возможности их завершения и вывода на исполнители, по меньшей мере, выглядят глупо, а в реальности могут привести к перегрузкам и зависанию всей программы (системы). Понятное дело я про полезную загрузку. Просто в этом общем цикле циркулируют одновременно разные цепочки. Какие-то завершаются, когда другие продолжают выполняться. Появляются новые. У человека мыслительный процесс тоже практически непрерывный, в котором он своим вниманием "перепрыгивает" с задачи на задачу. Цитата: Автор: Vpolevoj Поэтому, мне хотелось бы уточнить детали. Я всегда за. [Ответ][Цитата]
r Сообщений: 837	На: МЫШЛЕНИЕ Добавлено: 07 сен 16 15:53 Изменено: 07 сен 16 16:02 Цитата: Автор: r Но есть еще и четвертый путь (который я и пытаюсь реализовать в своей программе). Когда между собой связываются сразу ЧЕТЫРЕ функции. Я думаю от функций нужно отказываться. Это тупиковое развитие в области ИИ. Ну какой-то набор низкоуровневых функций должен быть. Но тут больше подходит термин действие (или операция). И не то чтобы низкоуровневых, скорее имеется в виду элементарных, простых. А вот из них нужно будет динамически складывать пазл решения под конкретную задачу. Вот тут TK правильно говорит: Цитата: Автор: TimKruz Функций можно сделать хоть мильён, а можно вообще без функций. Это детали конкретного кода. Разрабатывая алгоритм, не нужно вести подсчёт, сколько и каких функций использовать. Нужно продумать последовательность действий, которые должен выполнить исполнитель (компьютер), чтобы достичь результата. Разбивать на функции будем потом. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: МЫШЛЕНИЕ Добавлено: 08 сен 16 2:38 Цитата: Автор: VPolevoj ЧЕТЫРЕ функции Цитата: Автор: r Я думаю от функций нужно отказываться. Это тупиковое развитие в области ИИ. Вот тут TK правильно говорит: Цитата: Автор: TimKruz Нужно продумать последовательность действий, которые должен выполнить исполнитель (компьютер), чтобы достичь результата. Разбивать на функции будем потом. Под функциями я подразумевал вовсе не программные функции, а скорее - функционал, то есть, ту самую "последовательность действий, которую должен выполнить компьютер", вот только я хотел представить её не как Алгоритм (не как собственно последовательность), а как набор связанных между собой Функций (или Блоков, что на мой взгляд, примерно одно и то же). То есть, один Блок - это одна Функция, и есть еще и связи между ними, между этими Блоками-Функциями. Но в результате такого их соединения получается уже не Алгоритм (не "последовательность действий", как таковая), а скорее Конечный Автомат (КА), с некоторым ограниченным набором возможных состояний всей этой системы. И моя последняя схема из ЧЕТЫРЕХ связанных между собой Блоков-Функций дает, на мой взгляд, максимально возможное число подобных состояний при минимальном количестве взятых первоначально Функций-Блоков. То есть, создав (описав и запрограммировав) всего ЧЕТЫРЕ подобных Блока-Функции и связав их друг с другом указанным способом, мы получаем очень гибкую, и очень разветвленную систему состояний (КА), способную реагировать на изменяющиеся условия внешней и внутренней среды самым максимально разнообразным (при таком ограниченном наборе исходных Функций) образом. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: Программирование поведения робота без доступа к коду Добавлено: 08 сен 16 2:50 Изменено: 08 сен 16 5:39 Цитата: Автор: VPolevoj бесконечно циркулирующие в памяти процессы, без возможности их завершения и вывода на исполнители, по меньшей мере, выглядят глупо Цитата: Автор: r Понятное дело я про полезную загрузку. Просто в этом общем цикле циркулируют одновременно разные цепочки. Какие-то завершаются, когда другие продолжают выполняться. Появляются новые. У человека мыслительный процесс тоже практически непрерывный, в котором он своим вниманием "перепрыгивает" с задачи на задачу. У меня, в моей программе (Диалоговая Система) всё даже несколько круче. Поскольку я радею за унитарность (универсальность и однотипность всего и вся), то у меня вся программа запускается как один такой большой процесс. Помнится, мы говорили уже о том, что в программе должны быть Цели и Задачи, и что Цели, по идее, должны быть невыполнимыми, в отличие от Задач. Так вот, эта моя главная, или основная Задача, которую я запускаю самой первой, и выступает чем-то вроде недостижимой Цели, и её можно даже воспринимать "смыслом жизни" для самой этой программы, так как она никогда не будет программой достигнута. Но об этом знаю только я - её разработчик. А программа, уже в рамках попыток решить эту свою основную Задачу - Цель, генерирует для себя новые Задачи - Под-Цели, ну, и Человек ей подкидывает Задачи по ходу дела, не без этого... Хотя, теоретически, эта основная Задача, которую я запускаю самой первой, может быть решена (если программа сумеет найти и достичь "смысл свой жизни"), выведена на исполнители и завершена, так как она точно такая же как и все остальные Задачи. [Ответ][Цитата]
TimKruz Сообщений: 323	На: Программирование поведения робота без доступа к коду Добавлено: 08 сен 16 4:44 Изменено: 08 сен 16 4:46 Цитата: Я имел в виду цикл как нечто большее - "живой ансамбль" из постоянно реактивирующихся фактов в сочетании с как бы "объемной" совокупностью обработчиков, выполняющихся по возможности параллельно. Каким бы "живым" цикл ни был бы, он остаётся циклом. "Живость" зависит от того, что мы выполняем внутри него... Цитата: Этот цикл как бы блокирует поток, выполняющий его, вплоть до выхода из цикла. Делов-то - запустить цикл в отдельном потоке. Тогда другие потоки будут выполняться параллельно этому циклу (по возможности; зависит от числа ядер и загруженности ЦП), а цикл сможет менять значения переменных программы. Цитата: условие ( значение i изменилось значение i меньше значения n ) Как-то так можно: TCounter = class Data: Integer; Changed: Boolean; procedure Change(NewData: Integer); end; <...> i: TCounter; <...> procedure TCounter.Change(NewData: Integer); begin i.Data := NewData; i.Changed := true; end; <...> while i.Changed and (i.Data < n) do begin i.Changed := false; DoSomething; i.Change(i.Data + 1); end; При этом код while запущен в отдельном потоке (thread). Цитата: Выполнение инструкции увеличения i на единицу внутри условия снова активирует триггер "значение i изменилось", а так как триггер "значение i меньше значения n" все еще активен, то условие выполнится опять. Одного не пойму - если триггер "i изменилось" активируется внутри цикла, то это значит, что цикл никогда не будет прерываться (не считая второго триггера). Вот если бы i иногда изменялось бы, а иногда не изменялось - тогда такой финт ушами имел бы смысл. Цитата: если завести еще переменные j и m, аналогичные переменным i и n, создать для них такие же триггеры и такое же условие, то оба цикла будут выполняться параллельно Не будут. Каждый раз, когда цикл доходит до строчки end, он в любом случае возвращается на свою первую строчку и проверяет своё условие. Чтобы оба цикла выполнялись параллельно (как бы параллельно, если у нас только одно ядро - их итерации будут чередоваться) - нужно запустить их в отдельных потоках. В Delphi это делается одним щелчком пальцев. Ещё можно сделать один-единственный цикл для всех условий, как-то так: while true do begin if Trigger1 then Do1; if Trigger2 then Do2; if Trigger3 then Do3; <...> end; Тогда каждую итерацию этого цикла будет происходить проверка всех триггеров и выполнение всех действий, но строго по очереди. Использование потоков позволяет выполнять действия в наиболее оптимальном порядке, к тому же если какое-то действие зависнет или потребует больше времени, чем ожидалось - остальные потоки не будут ждать, а будут выполняться в штатном режиме. Поэтому я предлагаю использовать именно потоки. В общем, похоже, ты что-то не так понимаешь в программировании... Я готов всё объяснить. Цитата: Я думаю от функций нужно отказываться. Это тупиковое развитие в области ИИ. Ээээ, всё современное программирование построено на функциях (процедурах, методах или подпрограммах - называй как хочешь). Без них никуда, даже в ООП. Без них придётся писать огромную простыню кода, переписывать один и тот же код десятки раз... А работа ИИ не зависит от того, каким способом сконструирован его код - важен алгоритм, а не его конкретная реализация. Цитата: (универсальность и однотипность всего и вся), то у меня вся программа запускается как один такой большой процесс Я что-то не понимаю... Как "один большой процесс" может быть универсальным? В моей системе универсальность заключается как раз в раздробленности системы на множество модулей (DLL-библиотек) и обрабатывающих их потоков. Функционал системы зависит от того, какие модули будут подключены к ней, а т.к. модуль можно написать теоретически любой, то и система получается полностью универсальной... [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: МЫШЛЕНИЕ Добавлено: 08 сен 16 4:44 Изменено: 08 сен 16 5:07 Цитата: Автор: Vpolevoj ... в результате такого их соединения получается уже не Алгоритм (не "последовательность действий", как таковая), а скорее Конечный Автомат (КА), с некоторым ограниченным набором возможных состояний всей этой системы. Попробую проиллюстрировать это своё положение. Возьмём для начала зацикливание при помощи рекурсии. На что это похоже? Это похоже на пульсирующий орган, как например, сердце (в котором, кстати, есть свои внутренние ритмоводители). И тогда обработка информации в таком органе будет сводится к ВВОДУ информации, более или менее продолжительной "пульсации", и ВЫВОДУ на исполнители, как только результат будет достигнут. Перейдём к системе состоящей из ДВУХ Функций (Блоков). С точки зрения Конечных Автоматов (КА) их работа будет напоминать триггер (или маятник: Тик-Так, Тик-Так...). Но посмотрите чуть ближе. Когда входной блок (назовем его Сенсорным) получает первую порцию информации, то после небольшой предобработки он передает её в следующий блок (назовем его Исполнительным). А тот (тоже слегка перелопатив полученную информацию) смотрит, готово ли решение, и если он сочтет, что решение еще не готово, то возвращает запрос назад - в Сенсорный блок. И вроде бы, всё понятно. Но на самом деле, Исполнительный блок ведь не просто так возвращает свой запрос, а скорее всего указывает конкретную причину этого возврата: решение еще не готово (совсем), требуется уточнение, или попробовал, но не получилось и т.д. И поэтому Сенсорный блок - он же тоже не просто так, тупо, просто еще раз повторно переделывает уже выполненную один раз работу, а - с учетом этого запроса, то есть, либо ищет новое, либо дополнительно уточняет старое, либо ищет причины неудачи и т.д. То есть, информация не просто циркулирует между двумя этими блоками туда-сюда, а может ДОБИРАТЬСЯ в Сенсорном блоке, в зависимости от поставленной задачи, и ВЫВОДИТСЯ (частично) через исполнительный блок, как промежуточные решения либо как ПРОБЫ. И получается, что у первого блока (Сенсорного) два входа: один с сенсоров, а второй - со стороны Исполнительного блока; и один выход - в сторону Исполнительного блока. А у Исполнительного блока, наоборот, два выхода: первый - на исполнители и второй - в сторону Сенсорного блока; и один вход: со стороны Сенсорного блока. Как видите, даже в таком простейшем примере поведение этой системы выходит за рамки обычной "последовательности действий". [Ответ][Цитата]
TimKruz Сообщений: 323	На: МЫШЛЕНИЕ Добавлено: 08 сен 16 5:04 Vpolevoj, похоже, ты тоже не очень в программировании... Цитата: Возьмём для начала зацикливание при помощи рекурсии. На что это похоже? Это похоже на пульсирующий орган, как например, сердце Рекурсия - это вот: function F(X: Integer): Integer; begin if X > 0 then F := X * F(X - 1) // следующий этап рекурсии else F := 1; // выход из рекурсии end; Эта функция вычисляет факториал от X. То есть получаем такую последовательность действий: F(3) = 3 * F(2) = 3 * 2 * F(1) = 3 * 2 * 1 * F(0) = 3 * 2 * 1 * 1 = 6. Как видишь, никакой "пульсации" тут нет: происходит не цикл, а вложенный вызов, который "закручивает спираль", а когда X доходит до 0, "спираль раскручивается" и в точку вызова F(3) возвращается вычисленное значение 6. Цитата: с учетом этого запроса, то есть, либо ищет новое, либо дополнительно уточняет старое, либо ищет причины неудачи и т.д. Эти все теоретические выкладки - хорошо, но без конкретного алгоритма всё бесполезно. КАК сенсорный блок уточняет, ищет причины и т.д., если это просто сенсор? Если блок что-то делает - то это эффекторный блок. Сенсор просто считывает состояние среды. Цитата: Как видите, даже в таком простейшем примере поведение этой системы выходит за рамки обычной "последовательности действий". Не выходит. Какой бы сложной последовательность действий ни была, она остаётся последовательностью. Последовательность - ВНЕЗАПНО - может: ветвиться (if), зацикливаться (while), вызывать сама себя (рекурсия), разбиваться на несколько параллельных потоков (threads), и так далее. Но что ты с ней ни делай - она останется последовательностью. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: МЫШЛЕНИЕ Добавлено: 08 сен 16 5:25 Изменено: 08 сен 16 5:36 Цитата: Автор: TimKruz Vpolevoj, похоже, ты тоже не очень в программировании... Рекурсия - это вот: function F(X: Integer): Integer; begin if X > 0 then F := X * F(X - 1) // следующий этап рекурсии else F := 1; // выход из рекурсии end; TimKruz, спасибо тебе, конечно, за ликбез. Но похоже, что и ты не очень силен в программировании (особенно, в теоретической части). А без теории, как говорил И.В.Сталин, нам смерть. Посмотри, пожалуйста, что такое Автоматное программирование. А еще лучше - разберись. Цитата: Автор: TimKruz Эти все теоретические выкладки - хорошо, но без конкретного алгоритма всё бесполезно. А вот здесь есть и схемы (иллюстрации) и примеры алгоритмов. Надеюсь, что это окажется для тебя полезным. К тому же я считаю, что этот подход к программированию больше всего подходит для наших задач - для проектирования и создания ИИ. Цитата: Автор: TimKruz КАК сенсорный блок уточняет, ищет причины и т.д., если это просто сенсор? Если блок что-то делает - то это эффекторный блок. Сенсор просто считывает состояние среды. Нет, Сенсор - это сенсор, а Сенсорный блок - это блок обработки сенсорной информации. Точно так же, как и Исполнительный блок, который лишь обрабатывает информацию перед тем, как её вывести на непосредственно исполнители, а Исполнители - это просто исполнители. Например, у нас есть глаза (сенсор, хотя и там уже идёт предварительная обработка информации), а есть - зрительная кора (область в головном мозге). И что, как ты думаешь, прямо с этой зрительной коры сигналы идут непосредственно на исполнители? Нет, конечно: для связи с исполнителями (мышцами) есть другой отдел коры головного мозга - так называемая двигательная кора, а вот уже между ними - между зрительной корой и двигательной корой - устанавливаются взаимосвязи. Чем не моя модель (из двух связанных друг с другом блоков)? [Ответ][Цитата]
TimKruz Сообщений: 323	На: МЫШЛЕНИЕ Добавлено: 08 сен 16 7:07 Цитата: Но похоже, что и ты не очень силен в программировании (особенно, в теоретической части). А без теории, как говорил И.В.Сталин, нам смерть. Посмотри, пожалуйста, что такое Автоматное программирование. А еще лучше - разберись. Речь шла о рекурсии, что она вовсе не аналогична пульсации сердца. Автоматное программирование не имеет никакого отношения к рекурсии. Посмотрел, разобрался. Я такие программы ещё в школе на информатике писал - единственный цикл и оператор выбора состояния, всё просто. Цитата: К тому же я считаю, что этот подход к программированию больше всего подходит для наших задач - для проектирования и создания ИИ. ИМХО, записать алгоритм ИИ можно с помощью любого подхода, на любом языке и в любой парадигме - единственная разница в удобстве. А удобство - штука относительная: одному дико удобно ООП, другой шпарит чисто на процедурах, третий уважает только функциональные ЯП, четвёртый жить не может без формальных автоматов... Все мы разные, и у всех разные подходы к программированию. Цитата: Цитата: Эти все теоретические выкладки - хорошо, но без конкретного алгоритма всё бесполезно. А вот здесь есть и схемы (иллюстрации) и примеры алгоритмов. Я говорил не о примерах алгоритмов в автоматном подходе к программированию, а о реализации алгоритмов, о которых ты тут рассуждаешь. Описания в стиле "в цикле происходит изменение триггеров" или "всего используется ЧЕТЫРЕ функции в произвольном порядке" ни о чём не говорят и ни к чему практическому не ведут. Другими словами, вот я программировать умею - я могу написать реализацию ваших с r рассуждений, но пока я не вижу ни общей картины, ни деталей алгоритмов... (мой алгоритм интеллект-ядра пока в лёгком стазисе, ибо я немножечко запутался в нём... но он хотя бы как-то уже работает, уже можно поболтать за жизнь) Всё это похоже на блуждание вокруг да около проблемы без попыток на практике решить эту проблему. Извини, если тебя это заденет. Цитата: Нет, Сенсор - это сенсор, а Сенсорный блок - это блок обработки сенсорной информации. А, теперь понятно. Глаз как орган - это не только рецептор, но и эффектор - он подвижен и настраивается в зависимости от освещённости... Пы.Сы.: Нашёл классный редактор блок-схем, мож пригодиццо: https://drakon-editor.com/ [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: МЫШЛЕНИЕ Добавлено: 08 сен 16 12:39 Изменено: 08 сен 16 12:42 Цитата: Автор: VPolevoj Автоматное программирование Цитата: Автор: TimKruz Посмотрел, разобрался. Я такие программы ещё в школе на информатике писал - единственный цикл и оператор выбора состояния, всё просто. Да, все именно так - просто: единственный цикл и оператор выбора состояния. А ты не думал, что вся фишка заключается в этих самых состояниях: сколько их, откуда они берутся, как определяются, за счет чего происходит переключение между ними и т.д.? То есть, чем больше будет таких состояний у системы, тем значит, сложнее будет и сама эта система, и сложнее будет её поведение. Но просто так взять и "накидать" в систему различных состояний будет "не комильфо", нужно это как-то обосновать, а еще лучше вывести некую закономерность возникновения этих состояний, и совсем уж замечательно, если эта выведенная тобой закономерность описывает ВСЕ возможные состояния у этой системы (что бывает крайне редко). То есть, понимаешь, нам нужно смоделировать сложную систему (очень сложную), с большим количеством состояний, но при этом нам хотелось бы обойтись небольшим набором правил (закономерностей) для описания всех этих возможных состояний. Получается противоречие. Вот и крутимся, кто как умеет. [Ответ][Цитата]
Vpolevoj Сообщений: 1408	На: МЫШЛЕНИЕ Добавлено: 08 сен 16 13:01 Изменено: 08 сен 16 13:02 Цитата: Автор: TimKruz единственный цикл и оператор выбора состояния. Кстати, вот ты говоришь, что рекурсия - это не "пульсация", а скорее "закручивающаяся спираль". Да, ты прав. Если воспринимать эту рекурсию стандартно, как самовызов самой этой функции. А если воспринимать эту программу как КА (Конечный Автомат)? Вот, представь, есть у нас в программе "единственный цикл и оператор выбора состояния". А состояний-то всего ОДИН (не считая, конечно, того состояния, когда делать ничего не надо), и вызывается при этом состоянии одна-единственная функция. Состояние есть? Вызываем функцию. Функция отработала - вернула управление назад в цикл. Проверили состояние (а оно опять тоже самое) - вызвали функцию. Функция отработала... и т.д. Чем тебе не пульсация? Работа - пауза - работа - пауза... А когда в такой же точно системе ("единственный цикл и оператор выбора состояния") есть ДВА состояния, и, соответственно, две функции, то происходит последовательное переключение между ними: туда-сюда, туда-сюда, тик и так, тик и так... (триггер, одним словом). А если в такой системе ТРИ состояния, то - вариантов переключения, на самом деле, становится больше, чем просто три. Из состояния 1 можно перейти в состояние 2, а можно - в состояние 3, из состояния 2 можно уйти в 1, а можно - в 3, из 3 можно в 1, а можно - в 2. То есть, всего три состояния, но уже 6 возможных переходов. А когда мы закладываем в систему всего, казалось бы, ЧЕТЫРЕ состояния (это, согласись, немного), то количество вариантов взаимных переключений между ними вырастает до 12. А возможных ПУТЕЙ переключения (то есть, маршрутов, скажем, 1-2-3-4, или 1-4-3-2 и т.д.) становится так много, что их невозможно просто так взять и перечислить, выгоднее для этого использовать какую-нибудь закономерность. О чем я и пытался Вам всем сказать. [Ответ][Цитата]
TimKruz Сообщений: 323	На: МЫШЛЕНИЕ Добавлено: 09 сен 16 9:07 Изменено: 09 сен 16 9:29 Цитата: Да, ты прав. Если воспринимать эту рекурсию стандартно, как самовызов самой этой функции. Это единственное восприятие "рекурсии". Цитата: А если воспринимать эту программу как КА (Конечный Автомат)? Рекурсия - это рекурсия, а конечный автомат - это конечный автомат. Это разные вещи. Цитата: Состояние есть? Вызываем функцию. Функция отработала - вернула управление назад в цикл. Проверили состояние (а оно опять тоже самое) - вызвали функцию. Функция отработала... и т.д. Чем тебе не пульсация? Работа - пауза - работа - пауза... Это пульсация, но не рекурсия. Рекурсия не возвращает управление назад, пока не дойдёт до последней стадии (или пока не произойдёт переполнение стека вызовов). Цитата: А когда в такой же точно системе ("единственный цикл и оператор выбора состояния") есть ДВА состояния, и, соответственно, две функции, то происходит последовательное переключение между ними: туда-сюда, туда-сюда, тик и так, тик и так... (триггер, одним словом). Если это будет выглядеть так: repeat F1(state); F2(state); until false; Тогда это тоже просто цикл, а не рекурсия. Рекурсия - это вот: function F1(x: Integer):Integer; begin if x > 0 then F1 := F2(x - 1) else F1 := 0; end; function F2(x: Integer):Integer; begin if x > 0 then F2 := F1(x - 1) else F2 := 0; end; То есть получается вложенный вызов функций, вот так: F1(3) = F1(F2(2)) = F1(F2(F1(1))) = F1(F2(F1(F2(0)))) // "закрутились" = F1(F2(F1(0))) = F1(F2(0)) = F1(0) = 0. // "раскрутились" Это как если поставить два зеркала напротив друг друга и посмотреть в одно из них - вот это рекурсия. Но такая конструкция не вернёт управление в цикл, пока x не станет равно 0. Цитата: А когда мы закладываем в систему всего, казалось бы, ЧЕТЫРЕ состояния (это, согласись, немного), то количество вариантов взаимных переключений между ними вырастает до 12. А возможных ПУТЕЙ переключения (то есть, маршрутов, скажем, 1-2-3-4, или 1-4-3-2 и т.д.) становится так много, что их невозможно просто так взять и перечислить, выгоднее для этого использовать какую-нибудь закономерность. Я это понял ещё когда ты первый раз упомянул про четыре функции. Но мне совершенно непонятно, ЗАЧЕМ нам нужно делать четыре функции (состояния), и ЧТО в них будет происходить. Потому что просто анализировать входящий символьный поток (из чата, с видеокамеры, из микрофона) возможно в одной-единственной функции, которая по мере необходимости вызывает вспомогательные функции. Или цель "четырёх функций" - специально запутать работу алгоритма, чтоб реверс-инженеры все конечности переломали ("в твоём коде ногу сломишь")? Тогда понятно. Но запутывание кода происходит на последней стадии разработки софта, вводить эту путаницу в базовую архитектуру ИИ ни то что не нужно, а даже вредно - хрен его потом проанализируешь, чтобы все баги выловить... *** Кстати, возможных переходов 12, а число маршрутов, если нет повторяющихся вызовов - типа 1-1-1-1 - равно 4! = 24 (перестановка), а если повторяющиеся вызовы есть - то 4^4 = 256. Так что если ты хотел сделать дохрена возможных маршрутов - нужно брать более большие числа, четырёх тут явно недостаточно. [Ответ][Цитата]
victorst Сообщений: 821	На: Программирование поведения робота без доступа к коду Добавлено: 09 сен 16 22:45 Изменено: 09 сен 16 23:07 Цитата: Автор: r Тред посвящен проблеме описания неподготовленным человеком правил поведения робота. И, вероятнее всего, используя при этом язык близкий к естественному. Мне не совсем понятно, какие правила поведения робота здесь обсуждаются участниками диалога. Правила поведения, которые формулируем ограниченным ЕЯ или подобным способом, т.е. правила, которые мы запрашиваем у робота, требуем, чтобы он следовал им или его какой-то внутренний язык, внутренние механизмы, на основе которых робот действует? Если второе, то, я так понимаю, вы хотите некими своими алгоритмами запрограммировать робота, создав алгоритмически его поведение. Есть и другие подходы. [Ответ][Цитата]
Стр.9 (27): 1  ...  5  6  7  8  [9]  10  11  12  13  ...  27 << < Пред. | След. > >>