ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 84
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Популярность подхода связана с наглядностью и понятностью. Но очень остро для деревьев решений стоит проблема значимости. Дело в том, что отдельным узлам на каждом новом построенном уровне дерева соответствует все меньшее и меньшее число записей данных — дерево дробит данные на большое количество частных случаев. Чем больше этих частных случаев, чем меньше обучающих примеров попадает в каждый такой частный случай, тем менее уверенной становится их классификация. Если построенное дерево слишком "кустистое" — состоит из неоправданно большого числа мелких веточек ≈ оно не будет давать статистически обоснованных ответов. Как показывает практика, в большинстве систем, использующих деревья решений, эта проблема не находит удовлетворительного решения. Кроме того, общеизвестно, и это легко показать, что деревья решений дают полезные результаты только в случае независимых признаков. В противном случае они лишь создают иллюзию логического вывода.
Эволюционное программирование - проиллюстрируем современное состояние эволюционного программирования на примере системы PolyAnalyst. В данной системе гипотезы о виде зависимости целевой переменной от других переменных формулируются в виде программ на некотором внутреннем языке программирования. Процесс построения программ строится как эволюция в мире программ (этим подход немного похож на генетические алгоритмы). Когда система находит программу, достаточно точно выражающую искомую зависимость, она начинает вносить в нее небольшие модификации и отбирает среди построенных таким образом дочерних программ те, которые повышают точность. Таким образом система "выращивает" несколько генетических линий программ, которые конкурируют между собой в точности выражения искомой зависимости. Специальный транслирующий модуль системы PolyAnalyst переводит найденные зависимости с внутреннего языка системы на понятный пользователю язык (математические формулы, таблицы и пр.), делая их легкодоступными. Для того чтобы сделать полученные результаты еще понятнее для пользователя-нематематика, имеется богатый арсенал разнообразных средств визуализации обнаруживаемых зависимостей. Для контроля статистической значимости выводимых зависимостей применяется набор современных методов, например рандомизированное тестирование.
Пусть нам надо найти решение задачи, наиболее оптимальное с точки зрения некоторого критерия. Пусть каждое решение полностью описывается некоторым набором чисел или величин нечисловой природы. Скажем, если нам надо выбрать совокупность фиксированного числа параметров рынка, наиболее выраженно влияющих на его динамику, это будет набор имен этих параметров. Об этом наборе можно говорить как о совокупности хромосом, определяющих качества индивида — данного решения поставленной задачи. Значения параметров, определяющих решение, будут тогда называться генами. Поиск оптимального решения при этом похож на эволюцию популяции индивидов, представленных их наборами хромосом. В этой эволюции действуют три механизма: отбор сильнейших — наборов хромосом, которым соответствуют наиболее оптимальные решения; скрещивание — производство новых индивидов при помощи смешивания хромосомных наборов отобранных индивидов; и мутации ≈ случайные изменения генов у некоторых индивидов популяции. В результате смены поколений в конце концов вырабатывается такое решение поставленной задачи, которое уже не может быть далее улучшено.
Генетические алгоритмы имеют ряд недостатков. Критерий отбора хромосом и сама процедура являются эвристическими и далеко не гарантируют нахождения «лучшего» решения. Как и в реальной жизни, эволюцию может «заклинить» на какой-либо непродуктивной ветви. И, наоборот, можно привести примеры, как два неперспективных родителя, которые будут исключены из эволюции генетическим алгоритмом, оказываются способными произвести высокоэффективного потомка. Это особенно становится заметно при решении высокоразмерных задач со сложными внутренними связями.
Алгоритмы ограниченного перебора были предложены в середине 60-х гг. для поиска логических закономерностей в данных. С тех пор они продемонстрировали свою эффективность при решении множества задач из самых различных областей.
Эти алгоритмы вычисляют частоты комбинаций простых логических событий в подгруппах данных. Примеры простых логических событий: X = a; X < a; X > a; a < X < b и др., где X — какой либо параметр, a и b — константы. Ограничением служит длина комбинации простых логических событий. На основании анализа вычисленных частот делается заключение о полезности той или иной комбинации для установления ассоциации в данных, для классификации, прогнозирования и пр. Наиболее ярким современным представителем этого подхода является система WizWhy предприятия WizSoft, на практике продемонстрировавшая высокую эффективность при решении реальных задач.
15 . Главной подсистемой, которая управляет работой СППР, является ядро (диспетчер). Оно принимает запросы от интерфейса пользователя и преобразует их в вызовы процедур, содержащихся в библиотеке методов и моделей. Интерфейсом между ядром и СУБД служит подсистема манипулирования данными. Ядро формирует символьные строки команд для работы с базой данных и переадресует их для выполнения в подсистему манипулирования данными. Эта подсистема «знает», где находится база данных: на локальной машине или на другом сервере в локальной сети. Подсистема манипулирования данными выполняет команды и сообщает ядру результат: выполнено успешно или с ошибкой. Результаты запросов на выборку данных подсистема манипулирования данными передает ядру. Ядро готовит данные для передачи их функциям (процедурам), реализующим математические методы. При этом оно формирует необходимые структуры данных в памяти в том виде, в каком требуется для библиотеки методов и моделей. Ядро принимает результаты выполнения математических процедур от библиотеки методов и моделей и передает их для визуализации или формирует строки команд для вставки записей в таблицы базы данных. Ядро считывает файлы конфигурации и формирует необходимые глобальные структуры данных.
16 Требования к СППР.
1. Предоставление пользователю возможности описания структуры сложной системы. Структуру системы необходимо хранить в базе данных в виде матрицы, описывающей связи элементов. При этом необходимо хранить и информацию о характеристиках каждой такой связи: направленность связи (от первого элемента ко второму, от второго к первому, двусторонняя связь); сила связи (в обоих направлениях); тип связи (связь управления, информационная связь и др.); влияние этой связи на достижение глобальной цели всей системы и т. д.
2. Использование иерархического подхода при структуризации этапов исследования. За основу формирования логики работы с программным продуктом предлагается принять понятие «Исследование». Это понятие означает всю совокупность действий по обработке информации в процессе проведения исследования эффективности сложной системы. При этом необходимо учесть, что в рамках одного «Исследования» может исследоваться более одной системы. Аналогично, одна и та же система может быть объектом более одного «Исследования». Каждое «Исследование» может быть разделено на этапы, структура которых отражает структуру исследуемой системы и учитывает цели и задачи исследования.
У каждого этапа может быть этап-родитель. Для объединения этапов в связанные группы следует использовать этапы-контейнеры. С этапом-контейнером непосредственно не связывается выполнение каких-либо вычислительных операций. Например, этап-контейнер «Исследование эффективности факультетов» может содержать рабочие этапы «Научная работа на факультетах» и «Учебно-методическая работа на факультетах».
Для реализации идеи многовариантных расчетов необходимо предоставить пользователю возможность формировать для каждого этапа различные варианты исполнения. Такие варианты могут различаться наборами объектов и переменных, а также параметрами моделей. Анализ влияния вариаций на оценку эффективности должен выполняться в автоматизированном режиме (это должно делать ядро программного продукта).
3. Следование принципу «один этап – один метод». Все варианты конкретного этапа должны выполняться на основе одного и того же метода. Если требуется исследовать какую-то подсистему различными методами, то необходимо создать этап-контейнер и включить в него рабочие этапы, реализованные на основе требуемых методов. Данный подход позволит упростить реализацию механизма автоматизированного сравнения результатов многовариантных расчетов.
4. Использование концепции репозитория. Репозиторий содержит всю информацию, необходимую для проведения конкретного «Исследования»: описания объектов (в том числе и гипотетических объектов, предложенных при реструктуризации системы); описания переменных; описания структуры системы (или систем, если их больше одной); исходные данные (возможно, за несколько временных периодов); описания временных периодов.
Предлагается следующая иерархия уровней репозитория по степени детализации: уровень «Исследования»; уровень этапа «Исследования»; уровень варианта этапа «Исследования».
С точки зрения степени обобществления информации должен существовать:
– глобальный репозиторий (доступ к нему должен быть открыт для всех пользователей, выполняющих другие «Исследования»);
– локальный репозиторий (доступен только для пользователей, проводящих конкретное «Исследование»).
Данные, содержащиеся в репозитории «Исследования», должны быть представлены в оригинальном виде, т.е. без каких-либо преобразований. Преобразования данных целесообразно выполнять уже непосредственно при работе с данными в рамках проведения этапа (варианта этапа) «Исследования».
5. Разработка языка описания сценариев работы с СППР. Такой язык должен позволять пользователю описывать взаимосвязи элементов системы в терминах теории эффективности. Он должен использоваться для написания сценариев работы СППР в тех случаях, когда требуется проведение многовариантных расчетов, а также для реализации высокоуровневых методик, построенных на основе одного или нескольких методов оценки эффективности (подобные методики предлагались, например, в работах. В этом языке должны быть предусмотрены соответствующие типы данных и операторы. Пользователь должен иметь возможность сформировать сценарий работы согласно методике и сохранить его описание в базе данных с тем, чтобы затем воспроизводить написанный сценарий на различных наборах данных (на различных системах).
6. Организация коллективной работы. Коллективное использование программного продукта может быть организовано через локальную сеть или на одном компьютере. При этом необходимо обеспечить раздельный доступ к данным, принадлежащим различным пользователям.
7. Наличие средств гибкого конфигурирования СППР. При этом следует использовать иерархический подход: конфигурирование на уровне всей СППР, конфигурирование на уровне «Исследования», конфигурирование на уровне конкретного пользователя.