@PavelZX

Вы не поверите, отвечал как раз, на всех тут интересующий вопрос, в чем соль и где алгоритм то, инет отвалился и ответ потерялся такая формулировка получилась красивая, аж мне самому понравилась. Попробую сейчас это повторить, не обещаю, что выйдет также красиво

Кстати обновил файлы по сабжу https://bitbucket.org/PavelZX/uef/downloads по образам вообще и по объектам в частности.

Добавлено через 10 минут
Мяч, он круглый, маленький и лёгкий (не липкий). Можно его взять в руки и бросить, а можно и пнуть ногой. И предметы и действия в отдельности -- эти образы имеют признаки, по этим признакам можно найти все действия, что можно совершить с предметом или наоборот, к каким предметам можно применить это действие. Дополнительно ещё у нас имеются условия, в зависимости, к примеру, от расстояния до меча, к нему ещё нужно подойти, если он далеко.

Как собирать головоломку из разных предметов. По сути это и есть основа создания адаптационных алгоритмов, плюс сам набор признаков и действий можно пополнять разными новыми сущностями.

Добавлено через 7 часов 45 минут
Несколько мыслей по оптимизации распознавания (и почему не спешу пока приводить полные примеры кода объектов).

Вкус -- это особый параметр, СИМ и даже робот на его основе, не предполагает наличие вкусовых рецепторов, если конечно это не робот повар (впрочем и обоняние сделать работу очень не просто, в тоже время СИМ должен иметь понятие об этих признаках), при наличии признака несъедобный, остальные параметры исключаются. Ядовитый объект может иметь вкус, но живое существо может отравится, поэтому СИМу также не стоит хранить информацию о вкусе ядовитых веществ.

Список возможных звуков и запахов, присущих объекту огромен, поэтому информация от обонятельных рецепторов робота или от предпроцессора звуков, который также должен распознавать и фонемы человеческой речи, должна иметь более сложную форму, чем простой список значений. Предполагаю использовать для этого цифру, которая указывает какие пункты используются в описании. Также в системе должны быть константы указывающие длину списка этих параметров, на случай его расширения или хотя бы зарезервировать некоторое количество пустых изначально значений. К примеру используется 2, 4, 7 и 11 значения, то 01010010001 -- 291#. Но не сокращая значительно объём кода, мы в таком случае сильно усложняем систему распознавания. Очень не хочется также вводить в код какие-то либо управляющие символы, но и фиксированное количество признаков не есть хорошо, в плане возможного расширения. Всё-таки наверное стоит оставить фиксированный набор в ключе, а всё остальное кидать потом в хвост (значение).

Сразу вспоминается ограничения на размер ОЗУ первых компьютеров и размер также первых жёстких дисков, изначально больший объём памяти был недоступен, потом стали придумывать как это дело масштабировать. С другой стороны, во многих современных форматах висит хвост совместимостей со старыми.

Так как список признаков объектов и действий считаю основополагающим элементом квадрологики, то с одной стороны (в отличии от списка объектов и действий) его трудно будет пополнять, с другой стороны предусмотреть всё сразу нереально. Думаю обязательным будет добавить обобществляющий признак для звуков и запахов (возможно также и вкуса) указывающий наличие в наборе расширений, а с другой стороны присутствие некоего неопределённого, ни в основном наборе, ни в расширении признака! Блин, а иногда полезно правильно сформулировать задачу, решение может появится само собой.

Вернуться к обсуждению:
Аппаратно-программный комплекс имитации мышления Искусственный интеллект

0