Cтраница 1
Порождающие правила 8, 9, 10 дают проект нужного нам объекта. [1]
Изменить порождающие правила для арифметических выражений, приведенные в разд. [2]
Различные порождающие правила имеют разные правые части. [3]
Следующие три порождающих правила самые важные в нашей схеме. [4]
В настоящее время порождающие правила обычно реализуются в форме правил, манипулирующих с символическими структурами типа списка векторов, а не строк символов. В этом сказывается влияние языков программирования вроде LISP и тех структур данных, которые они поддерживают. [5]
Этот модуль формирует порождающие правила, используя в качестве входной информации описание дерева решений. Подробное описание этой программы имеется в технической литературе, а потому мы не будем останавливаться на ней в данной книге. [6]
Пример показывает, что порождающие правила могут дать некоторое множество решений. Для выбора наилучшего из них следует добавить дополнительные требования. На вход системы поступают требования, на выходе - схема из функциональных элементов. [7]
Таким образом, если применять порождающие правила в последовательности 2, 2, 3, 5, 1 к исходному символу предложения 5, порождается гюследователь-ность терминальных символов aaaba. Очевидно, что применение правил в другой последовательности даст другую последовательность символов. [8]
Хотя в приложении к экспертным системам порождающие правила и отличаются от тех правил переписывания, о которых шла речь выше, фундаментальные принципы и формальные свойства их остаются теми же. [9]
Наконец, в пункте ( в) обнаруживаем порождающие правила, начинающиеся символами В и ТХ. [10]
Для таких метапонятий существуют отдельные ( мета) порождающие правила, определяющие их в терминах других понятий. [11]
Информация из таких стилизованных формуляров довольно просто преобразуется в порождающие правила. Но система SALT не только переводит полученную информацию в формат правил, но и анализирует соответствие между новым правилом и ранее введенными. Поэтому желательно сначала ввести информацию для всех правил типов PROCEDURE и CONSTRAINT, а уже затем вводить информацию для правил типа FIX. [12]
Мы уже не раз обращали ваше внимание на то, что порождающие правила позволяют представить в программе эмпирически выявленные связи между условиями и действиями, между наблюдениями и гипотезами, но они значительно хуже подходят для представления отношений между объектами предметной области, включая и такие важнейшие, как отношения множество / элемент или множество / подмножество. Структурированные объекты, например фреймы, оказываются более удобным средством для хранения и манипулирования описаниями объектов предметной области, но применение таких знаний требует включения в программу фрагментов программного кода ( например, на языке LISP), которые затем трудно анализировать. Рациональное зерно в первых попытках свести вместе стили, основанные на правилах и фреймах, состояло в том, чтобы объединить способность представлять объекты, характерные для фреймов, с возможностями связывать условия и действия с помощью порождающих правил. [13]
Хотя и R1, и MYCIN являются программами, использующими в своей работе порождающие правила, между ними имеется ряд серьезных отличий. Сначала программа определяет множество компонентов и далее пытается сконструировать такую конфигурацию этих компонентов, которая удовлетворяла бы ограничениям, вытекающим как из характеристик отдельных компонентов, так и из отношений и связей между ними. [14]
На диаграмме акцептора следует заменить метки вершин нетерминальными символами и затем по меткам, ребер восстановить порождающие правила. [15]