Реферат: Нейросетевая реализация системы

В реализации программы мы существенно использовали идеи объектных шаблонов из [Gamma]. Далее, в описании реализации системы мы будем использовать русскоязычные аналоги терминов, введенных в [Gamma], поэтому, чтобы не возникло путаницы, отметим, что Фабрика соответствует Factory, объектные шаблоны – design patterns, Синглетон – Singleton, Chain of Responsibility – Цепочка Обработчиков. Названия классов объектов будут выделены курсивом и начинаться с заглавной буквы. Отметим, что идея шаблонов в программировании и computer science оказалась весьма плодотворной и слово “шаблон” здесь мы используем в трех различных смыслах: объектный шаблон (design pattern), просто шаблон (в смысле определения 1.x.5) и C++ - шаблон (template).

Мы опишем только реализацию ядра системы. Следование принципам открытости предполагает закладывание возможности развития системы через добавление надстроек над ядром (рис. 5.2). Мы, по возможности, старались следовать данному принципу. В частности, одним из направлений развития мы видим создание конструкторов библиотек шаблонов (а, следовательно, и сетей) с помощью ГИП. Предполагается, что выходным продуктом этих конструкторов будут файлы спецификации шаблонов, с которыми уже умеет работать ядро, из которых и будут формироваться библиотеки шаблонов. Далее, можно было бы создать трехмерный визуализатор БЗ (об этом далее), также мы считаем, понадобится отдельный инструмент для конструирования самих БЗ, а, возможно, при определенном уровне сложности блоков УС, и для каждого из них по отдельному инструменту, которые бы учитывали в полной мере специфику блоков УС.

Рис. 5.2.

5.3. Конструкторы сетей. Библиотеки шаблонов.

Как уже было отмечено, конструкторы сетей ядра СПИНС предназначены для создания внутреннего представления сети в памяти компьютера по различным источникам. Здесь будет рассмотрен только один - конструктор по файлу-спецификации сети, но мы не исключаем возможности создания конструкторов, использующих другие источники.

Конструктор по сути своей является фабрикой объектов класса ЭлементСети. Идея фабрики состоит в следующем. Поскольку конструирование сети состоит в порождении огромного числа разнородных объектов ЭлементСети, то необходим объект для регулировки процесса порождения и смерти этих объектов, или фабрика элементов сети. То есть на Фабрику также возложены функции сборщика мусора. Регулировка или управление процессом порождения состоит в следующем. Мы имеем много разных потомков класса ЭлементаСети, например, Нейрон, который, в свою очередь имеет несколько подклассов, соотвествующих каждой из разновидностей формальных моделей, а также другие элементы сети Блок, Источник, имеющий также несколько своих подклассов и т.д. Предположим, мы модифицировали или создали новую версию класса A из перечисленных классов - . Тогда в каждом месте исходного текста мы должны заменить оператор порождения A на оператор порождения . Более гибкой является следующая схема. Фабрика1 умеет, или точнее выражаясь, имеет методы для порождения объектов классов А, B, C и т.д. При сообщении о порождении, например, объекта типа А, она порождает на самом деле объект потомка А: , а Фабрика2 порождает в данном случае . Таким образом, заменой только фабрик мы можем менять классы порождаемых объектов. Отметим, что фабрика на языке C++ естественным образом реализуется через С++ - шаблон (template) и параметризуется типом порождаемых объектов. Ссылка на ФабрикуЭлементовСети, умеющую порождать каждый из конечных потомков ЭлементСети, хранит объект Сеть. При инициализации КонструктораСети ему сообщается ссылка на Сеть. Естественно, Сеть еще не содержит ЭлементовСети, но уже должна иметь ссылку на ФабрикуЭлементовСети. При конструировании сети по файлу спецификации КонструкторСетиПоФайлу (подкласс КонструктораСети) использует методы порождения объектов ФабрикиЭлементовСети, ссылку на которую он берет у Сети.

Отметим здесь, как решена была проблема передачи параметров конструктору (инициализатору, особому методу, вызывающемуся первым после размещения объекта в памяти) элемента сети и, вообще, конструктору любого объекта, порождение и удаление которого находится под управлением фабрики. Проблема состоит в унификации типа передаваемых параметров: они должны быть одни и те же для всех типов элементов сети. Был введен класс Атрибут и методу порождения объекта у фабрики и, соответственно, конструктору объекта передавался список Атрибутов. Каждый Атрибут имеет имя, и конструктор каждого элемента сети распознает только некоторое подмножество подклассов Атрибута, “свои атрибуты”, которые узнает по имени. Например, АтрибутВероятности является подклассом Атрибута, имеет свое поле рационального типа вероятность. Конструктор Нейрона2 распознает АтрибутВероятности в переданном списке атрибутов и использует значение его поля вероятность для инициализации Нейрона2. Для атрибутов также понадобилась ФабрикаАтрибутов.

При создании Фабрики был использован еще один объектный шаблон, так называемый Синглетон. Синглетон решает задачу обеспечения единственности экземпляра класса и управляет доступом к этому экземпляру.

Теперь о самой спецификации. При создании языка спецификации ставились следующие задачи:

Максимум широты спектра описываемых сетей, или максимальная гибкость языка

Относительная простота и удобочитаемость

Минимальная длина спецификаций

Возможность развития языка

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

[Meta]set for Neuron2 synonym Nset for Brancher synonym I[Inputs]I1,I2,I3,I4[Outputs]I1,I2,I3,I4,N1,N2,N3,N4

[Net Topology]

set for N default connection attribute delay=0

set for N default attribute study_counter=3

DecisionMaker(actions=0,1)

StochasticSource(probability=0.1,value=2)

Max[DecisionMaker,StochasticSource]

Env[or]

I1[Env(contact_number=0,delay=1)]

I2[Env(contact_number=1,delay=1)]

I3[Env(contact_number=2,delay=1)]

I4[Env(contact_number=3,delay=1)]

N1[I2,I3,I4]

N2[I1,I3,I4](study_counter=4)

N3[I1,I2,I4]

N4[I1,I2,I3]

Пример 5.3.1. Спецификация сети.

Спецификация состоит из секций. Секция начинается с указания имени секции в квадратных скобках и состоит из операторов спецификации. В Meta секции собраны операторы, область применения которых – вся спецификация, т.е. все секции. Здесь, например, можно задать имена–синонимы для шаблонов. Во многих секциях может появляться оператор set. Обычно, его синтаксис таков:

set for <имя-приемника> <что-установить> <значение>.

Например, set for Neuron2 synonym N устанавливает имя-синоним N для шаблона Neuron2. В секциях Inputs и Outputs просто перечисляются входы и выходы сети. Самая большая секция, обычно, Net Topology, где описывается топология сети. Ссылка на элемент сети в спецификации состоит из двух слитных слов: указания имени типа элемента сети (или его синонима) и его некоторого порядкового номера, причем нумерация для каждого типа своя. Описание топологии состоит из операторов описания топологии, в которых указывается некоторый элемент сети, его входы в квадратных скобках, причем в круглых скобках после указания каждого входа может стоять ассоциативный список (т.е. список пар имя-значение) атрибутов связи, и, дополнительно, после перечисления входов, может быть, в круглых скобках ассоциативный список атрибутов элемента. Каждая связь двух элементов сети может характеризоваться некоторым множеством атрибутов связи. Например, атрибутом связи может быть синаптическая задержка. Каждый элемент сети понимает свой набор атрибутов связи, некоторое множество атрибутов связи обрабатывается ядром системы, и, как мы уже упомянули, каждый элемент сети понимает свой набор атрибутов (элемента сети), значения которых могут передаваться в списке атрибутов элемента.

В примере спецификации 5.1 используются имена некоторых встроенных шаблонов, например, Neuron2 или Brancher. Вообще говоря, ядром поддерживается некоторое множество встроенных базовых шаблонов и в языке есть конструкция для определения новых шаблонов через уже определенные или встроенные. Информация об уже определенных шаблонах хранится в специальном объекте БиблиотекаШаблонов, являющемся Синглетоном и имеющем методы для получения идентификатора шаблона по его имени, извлечения информации о шаблоне по его идентификатору, а также добавления / удаления шаблонов. Если КонструкторСети при чтении спецификации встречает имя шаблона или конструкцию определения нового шаблона, то он обращается к БиблиотекеШаблонов для, соответственно, получения информации о шаблоне по имени или для добавления нового шаблона. Таким образом, пользователь может создавать библиотеки своих шаблонов, определения которых хранятся, например, в файлах и при их использовании просто включать соотвествующие файлы в своих спецификациях с помощью конструкции языка, аналогичной “#include” в языке C / C++. Отметим, что библиотечные файлы шаблонов могут создаваться специальным инструментом, конструктором шаблонов.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8