From e6f681d87a9c9940ca9ffd8f4b87f8f200683fe2 Mon Sep 17 00:00:00 2001 From: Google Code Exporter Date: Thu, 6 Aug 2015 15:58:07 -0400 Subject: [PATCH] Migrating wiki contents from Google Code --- Architecture.md | 1 + Models.md | 0 OptimalControl.md | 25 +++++++ ProjectHome.md | 15 +++++ Protocol.md | 167 ++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 208 insertions(+) create mode 100644 Architecture.md create mode 100644 Models.md create mode 100644 OptimalControl.md create mode 100644 ProjectHome.md create mode 100644 Protocol.md diff --git a/Architecture.md b/Architecture.md new file mode 100644 index 0000000..315c5b0 --- /dev/null +++ b/Architecture.md @@ -0,0 +1 @@ +# Встроенный сервер # \ No newline at end of file diff --git a/Models.md b/Models.md new file mode 100644 index 0000000..e69de29 diff --git a/OptimalControl.md b/OptimalControl.md new file mode 100644 index 0000000..3e0a6ba --- /dev/null +++ b/OptimalControl.md @@ -0,0 +1,25 @@ +# Введение # + +В окружающем мире большинство процессов протекают непрерывно с течением времени. Вода не льется из под крана маленькими кубиками, она течет постоянной непрерывной струей, машина не едет "рывками", она плавно едет по извилистой змейке дороги. + +Но, тем не менее, почти все непрерывные процессы мы можем представить в качестве дискретных. Струю воды можно считать по каплям, а путь автомобиля по пройденным сантиметрам. Такой подход несколько неудобен для человека, который привык к плавности движений и форм. Однако, для вычислительных машин нет ничего лучше! Компьютеры все меряют отдельными значениями. Но если маленьких отдельных значений очень много, то они становятся похожи на непрерывный набор данных, поэтому, в сущности, какая в конечном счете разница что использовать: непрерывные функции или их дискретные аналоги? + +# Дискретная задача # + +Дискретную задачу оптимального управления можно рассматривать и описывать как многошаговый процесс. На каждом шагу такой процесс характеризуется набором переменных состояния (фазовых переменных) _X_ = (xk1 ... xkn) и набором переменных управления _U_ = (uk1 ... ukn). Если подробнее, то на каждом шаге процесс описывается некоторым набором значений, которых характеризуют его состояние, а также переменными, которых характеризуют воздействие на процесс. + +## Начальные условия ## + +Изначально нам известны только стартовые параметры системы, а, так как процесс изменяется со временем, вычисляются с помощью заданной функции, которая определяет динамику процесса. В общем случае + +f = f(xk, uk, k), + +но может быть и так, что на каждом выбранном промежутке функция будет разной. + +## Условие оптимальности ## + +В общем случае задача управления дискретным процессом состоит в нахождении такого допустимого процесса, при котором функция + +_I_(_U_) = _F_(xq} + Sum( fi(xk, uk, k), i = 0 .. q-1 ) + +стремится к минимуму (максимуму). В этой функции _F_() - заданная функция. \ No newline at end of file diff --git a/ProjectHome.md b/ProjectHome.md new file mode 100644 index 0000000..841536c --- /dev/null +++ b/ProjectHome.md @@ -0,0 +1,15 @@ +Легкое и удобное управление моделями поиска оптимального управления. + +Суть разработки в том, чтобы отделить сам алгоритм от всех "красивостей", которые уже будут реализованы в платформе. Это позволит программистам, занимающимся разработкой алгоритмов для решения задач оптимизации, сосредоточиться на самой задаче и не отвлекаться на создание графического интерфейса, графиков, таблиц отчетов. Среди запланированных возможностей платформы: + + 1. Готовый универсальный графический интерфейс. Чтобы алгоритм заработал на этом интерфейсе нужно всего лишь написать несколько строк кода, которые будут работать по необходимому протоколу и обеспечат связь между графическим интерфейсом и алгоритмом. Сейчас я как раз проектирую данный протокол с целью сделать его максимально простым и удобным в использовании. + 1. Возможность управлять моделями и "методами" их решения. Под "методом" я понимаю алгоритм, который будет решать ту или иную модель: генетический алгоритм, метод проекции градиента, метод Беллмана и др. Можно будет создать одну модель, создать для нее несколько методов решения, чтобы узнать какие параметры будут более точны. Или создать несколько моделей (например, с разными коэффициентами в уравнениях), связать их с одним методом. И пока программа в автоматическом режиме производит расчеты, собирает данные и строит графики, не спеша выпить кофе. + 1. Возможность построения графиков одной или нескольких моделей на одном листе, для того, чтобы быстро и в наглядной форме можно было сравнить (например) как от изменения одного параметра изменяется поведение результата. Несколько нажатий клавиш, и подробный отчет будет сделан! + 1. Встроенные возможности экспорта таблиц в различные форматы: TeX, Excell, plain text и другие. + +Еще несколько особенностей, которые я не буду включать в диплом из-за их громоздкости, но тем не менее, если проект вызовет интерес, их можно будет реализовать. + + * Сетевой вариант приложения. Управлять с одного компьютера, например, ноутбука, в то время как все вычисления могут производиться на отдельном сервере. Зачем загромождать свой рабочий компьютер, ведь его назначение - управлять! Расширяя эту возможность, можно разработать web-интерфейс, который позволит управлять всеми задачами из любого места в сети. + * Возможность запуска задач не в виде написанного алгоритма, а в виде математической нотации, где для решения будут применяться уже готовые проверенные алгоритмы. Это несколько снизит скорость работы алгоритмов (универсализация всегда приводит к снижению скорости), но позволит проектировать и запускать задачи не имея больших навыков в программировании. + +**It's brilliant! No. It's Opal.** \ No newline at end of file diff --git a/Protocol.md b/Protocol.md new file mode 100644 index 0000000..eea1b99 --- /dev/null +++ b/Protocol.md @@ -0,0 +1,167 @@ + + +--- + + +# Общие сведения # + +Протокол Opal специально разрабатывался с такой целью, чтобы быть максимально простым в использовании как человеку, так и машине. Не смотря на простоту, протокол обладает большой гибкостью и лаконичностью. + +Описание протокола можно разделить на две части. Такое разделение связано с архитектурой проекта. Тем не менее, формат сообщений универсален. + +## Формат сообщения ## + + +Все сообщения строятся по одному шаблону, очень похожему на протокол JSON. В основе выбранного стиля лежит набор пар ключ-значение, которое в большинстве языков программирования представляется в виде ассоциативного массива. + +В общем случае сообщение выглядит следующим образом - это набор пар ключ-значение, заключенный в фигурные скобки. +``` +{ тело сообщения } +``` + +Пример простейшего сообщения: +``` +{ request = info } +``` + +## Ключевые слова ## + +Некоторые из ключей являются специальными словами, жестко установленными, для возможности адекватного общения меду сервером и клиентом. + +| **Слово** | Краткое описание | +|:----------|:-----------------| +| request | запрос какой-либо информации | +| answer | ответ на запрос | +| status | статус опрашиваемого процесса | +| main | секция с описанием параметров модели | +| algo | секция с описанием алгоритмов-методов модели | +| header | секция с описанием заголовка таблицы результатов | +| table | секция с описанием таблицы результатов | +| comment | комментарий | + +Теперь более подробно о каждом из ключевых слов. + +### request ### + +### answer ### + +## Типы данных ## + +# Соединение сервер - задача # + +## Запрос информации сервером ## + +Перед запуском задачи для того, чтобы узнать какие параметры нужно передавать для корректного выполнения алгоритма, сервер запускает задачу с ключом -i или --info: + +`task (-i|--info)` + +Результатом работы будет набор строк, который описывает все доступные значения для данной задачи. Строки описываются в следующем формате: + +_name_ = _type_ (choice _list_) (default _value_) + + + +В ответе обязательно должна присутствовать секция Main, в которой описываются все параметры модели. Другие секции описывают параметры доступных алгоритмов в задаче и их количество не ограничено. + +## Передача списка параметров ## + +## Получение результата ## + +# Соединение сервер - ГИП # + +# Пример сессии # + +``` +// запрос сервера на получение информации о задаче +{ + request = info +} +// ответ клиента-задачи +{ + answer = ok + + meta = { + detailed = true + } + + main = { + size = int default 100 + x = float default 20.0 + y = float default 0.0 + time = period default 00:00 to 24:00 comment twenty-four hours + } + + algo = { + + genetic = { + method = string choice [std, last] default std + poplulation = int default 1000 + } + + bellman = { + xpart = float partition 0 to 100 by 1 + ypart = float partition 0 to 50 by 0.5 + } + } +} +// запрос сервера на вычисления по указанным параметрам +{ + request = calculate + + main = { + size = 100 + x = 20.0 + y = 5.0 + time = 00:00 to 48:00 + } + + algo = { + genetic = { + method = last + population = 1200 + } + } +} +// ответ клиента задачи о том, что вычисления начались +{ + answer = ok + status = inprogress +} +// запрос сервера о статусе вычислений +{ + request = status +} +// ответ клиента-задачи о том, что прошла уже половина вычислений +{ + answer = ok + status = inprogress + percent = 0.50 + comment = 10 минут, полет нормальный +} +// снова запрос сервера о статусе +{ + request = status +} +// клиент сообщает, что вычисления завершены, и предоставляет таблицу результатов +{ + answer = ok + status = ready + + header = { + time = datetime + x = float + y = float + u = float comment management + } + + table = { + 00:00 20.0 5.0 0.0 + 01:00 18.0 6.0 1.0 + 02:00 16.0 7.0 2.0 + //... + } +} +``` \ No newline at end of file