[Golem-iq]

Доброго времени суток! Начался новый семестр и нужно выбирать тему для научно исследовательской работы. Год назад я делал диплом по "Расчёт и отрисовка системы вентиляции", тогда в замечании к диплому мне написали, что отсутствует дерево построения. Под деревом построения понималась возможность ветвить расчёт системы. К примеру на основном блоке системы (допустим кондиционер), обычно существовало несколько вариантов и здесь должно быть ветвление, что бы по окончанию расчёта для одного блока, можно было заменить блок и пересчитать. Таких точек ветвления может быть много, поэтому можно получить довольно большое дерево.
Теперь сам вопрос: Подскажите, насколько сложна будет данная задача в осуществлении?
Язык желательно LISP, точку разветвления пользователь пускай задаёт сам (по нажатию на кнопку на ленте), управление деревом тоже на ленте (отдельную вкладку нужно будет сделать). Тут ещё всплывает вопрос как хранить состояние в определённой точке? Ведь помимо самого чертежа, ещё есть набор lisp-переменных, хранящих параметры системы.
Выслушаю все пожелания! Даже в том что идея довольно бредовая =)
ЗЫ: Поиск по форуму ничего выдал, потому что идут результаты о SolidWorks. Если где такая проблема поднималась, буду рад, если поделитесь ссылкой.

[skkkk]

Представь, что ты программист, и ничего не знаешь о системах ОВ. Теперь перечитай свой пост и подумай: сможешь написать программу на основании его? Думаю, вряд ли. Даже оценить сложность не удастся. Чтобы хоть что-то стало хоть кому-то понятным, весьма желательно приложить файл с изображением того, что хотелось бы получить, сопроводить всё это пояснениями. Тогда может получиться предметный разговор.

[Golem-iq]

Сообщение от skkkk Представь, что ты программист, и ничего не знаешь о системах ОВ. Теперь перечитай свой пост и подумай: сможешь написать программу на основании его? Думаю, вряд ли. Даже оценить сложность не удастся. Чтобы хоть что-то стало хоть кому-то понятным, весьма желательно приложить файл с изображением того, что хотелось бы получить, сопроводить всё это пояснениями. Тогда может получиться предметный разговор.

Уйдём от систем ОВ. Пускай у нас есть программа по выбору машины. Прям по пунктикам: выбор марки; выбор движка; выбор цвета и т.д. Ниже я привёл примерный вид дерева для такой последовательности. Читать снизу вверх.

В итоге мы имеем несколько вариантов при "возврате к точке":
1) пересчитать под новый выбор и заменить все узлы в ветке идущие после.
2) пересчитать под новый выбор и сделать копию ветки с новыми параметрами.
3) начать собирать новую ветку.
Какой способ выбрать, решает пользователь.
Но как организовывать хранение самой точки? Может есть какие-нибудь источники?

[bargool]

т.е., по сути, ты хочешь построить дерево принятия решений?

[Golem-iq]

Сообщение от bargool т.е., по сути, ты хочешь построить дерево принятия решений?

Ну с оооочень большим натягом. И то не очень близко( Смысл в том что бы можно было возвращаться в какую либо точку и начинать расчёт заново. То есть точка должна хранить состояние чертежа и переменных в определённый момент. А то что прислали Вы, используется для анализа систем и уже как основа принятия решений для какого либо ИИ, при обучении с учителем.

А я кроме как делать обычный файл сохранения не знаю, пока решения.

[Дима_]

Сообщение от Golem-iq То есть точка должна хранить состояние чертежа и переменных в определённый момент.

При такой организации 100% наплодишь ошибок т.к. количество вариатнов проверок корректности очень быстро будет стремится к бесконечности. Формируй список аргументов для построения всей системы "с нуля" - только так.

[Golem-iq]

Идея очень ценна! Но я так понял, что нужно будет при возврате к точке рассчитывать всё заново от корня до точки. Но в системе присутствуют ресурсоёмкие вычисления. Это будет не очень приятно для пользователя.
Хотя идея создания файла с шагами, а потом его выполнение, мне очень понравилась! Можно будет избежать затрат на хранение чертежей и переменных.
А не приходилось ли встречаться с описанием таких решений? хотелось бы почитать что-нибудь.

Вот сюда попробуй обратиться, там много толковых парней - DEM, SWELL{d}...такие проги им как два пальца...
http://forum.dwg.ru/showthread.php?p...06#post1050506

[Дима_]

Сообщение от Golem-iq Но в системе присутствуют ресурсоёмкие вычисления

Кэширование, мемоизация, отложенные вычисления... Но с автолиспом будет много костылей и велосипедостроения.

[Golem-iq]

Сообщение от Дима_ При такой организации 100% наплодишь ошибок т.к. количество вариатнов проверок корректности очень быстро будет стремится к бесконечности. Формируй список аргументов для построения всей системы "с нуля" - только так.

Благодарю за дельные советы! Попробую протолкнуть тему научному руководителю. Жаль, что он в данной тематике мало что понимает, а разбираться уже лень

[skkkk]

Сообщение от Golem-iq Но как организовывать хранение самой точки?

Можно попробовать реализовать хранение значений (шагов) в свойствах чертежа (тех, которые Файл -> Свойства чертежа...; команда _dwgprops). Записать туда значение, как и прочитать его лиспом не составляет труда. Вопрос в алгоритме.

[DEM]

Сообщение от SergeyAB Вот сюда попробуй обратиться, там много толковых парней - DEM, SWELL{d}...такие проги им как два пальца... http://forum.dwg.ru/showthread.php?p...06#post1050506

Offtop: Договоришься....

[ShaggyDoc]

Если бы это была не научно-исследовательская работа, а реальная программа, да не было бы научного руководителя, а была бы цель получить результаты, то всё бы решилось достаточно просто.
Не надо было бы думать про "дерево построения" и прочее. Зато надо было бы думать, а как именно (технически) пользователь "пускай задает сам". В научных работах это опускается. Но упоминается LISP. Это какой - в AutoCAD? Или Lisp "вообще"? Язык программирования, конечно, особого значения не имеет, но зато имеет решающее значение среда разработки.

Если делать на AutoLisp, да в AutoCAD, то там никакие "ленты" не помогут. На "лентах" (ribbon, что ли?) можно разместить отдельные кнопки, к каждой из которых привязать LISP-функцию для чего-то (добавить ветвь, удалить и т.д.). Это получится набор самостоятельных "программ", которые должны работать с едиными данными. Отсюда и все возможные беды с сохранением состояния. А тут возможности ограничены:
1. Глобальные переменные во время одного сеанса (что смао по себе плохо)
2. Сохранение внутри файла чертежа (в разных словарях)
3. Сохранение вне чертежа - файл, реестр.

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

А как такие задачи практически решаются? Если все-таки вернуться к системе вентиляции, то "расчет и отрисовка" делится на две задачи - "расчет" и "отрисовка". Нарисовать реальную схему вентиляционной системы автоматически нереально. Но можно нарисовать "плоскую" расчетную схему в виде дерева, отражающего топологию системы.

Такое дерево имеет узлы (точки соединения) и участки воздуховодов (или труб). Смысл всех таких расчетов сводится к вычислению сопротивлений участков и общего сопротивления. При этом подбираются или задаются диаметры воздуховодов. Математические вычисления каждого отдельного участка просты - 2-3 формулы. Расчет системы в целом математически прост (суммирование сопротивлений или проводимостей). Проблема возникает в том, как программа "узнает", что с чем суммировать и как описать это на языке программирования.

Ну, это была присказка, теперь сказка. Как это делается практически (как "научно" - представления не имею, мы люди тёмные, гимназиев не кончали):

1. Выбирается подходящая, правильная среда программирования. Такая, в которой есть необходимые компоненты (классы). Возьмем, для примера Delphi.
2. Создается база данных. Формат - по вкусу. Проще всего MDB. В БД создаются необходимые таблицы. Одна из них (основная) - для хранения самого дерева. Типовая схема для дерева - наличие полей для ID участка, ID родителя и имени участка.
3. Для работы с БД - компоненты TAdoDatabase и соответствующее количество TDataSource и TDataSet
4. Для отображения дерева - какой то вариант TDbTreeView. Который умеет и добавлять ветви и редактировать.
5. Для отображения других данных - набор каких нужно Edit.

Вот в принципе и всё. Дальше - дело техническое. Все состояния всего постоянно автоматически запоминаются в базе данных. Все пересчеты можно делать автоматически привязкой к событиям BeforePost и AfterPost. А можно и отдельной кнопкой. По данным дерева можно его топологию и нарисовать, хоть в AutoCAD, хоть просто на Canvas.

Но всё это - при отсутствии научного руководства. Потому как всё это ненаучно.

[Дима_]

Сообщение от ShaggyDoc Создается база данных. Формат - по вкусу. Проще всего MDB. В БД создаются необходимые таблицы. Одна из них (основная) - для хранения самого дерева

Способ конечно рабочий, но зачем здесь "городить" mdb. Я бы сделал рекурсивную структуру с экспортом в XML и настройками отображения - с деревьями работать при помощи реляционных БД - это ИХМО не самый лучший выбор - а "плясать" от имеющегося функционала классов - это тупиковый путь.

[ShaggyDoc]

Сообщение от Дима_ Способ конечно рабочий, но зачем здесь "городить" mdb. Я бы сделал рекурсивную структуру с экспортом в XML и настройками отображения - с деревьями работать при помощи реляционных БД - это ИХМО не самый лучший выбор - а "плясать" от имеющегося функционала классов - это тупиковый путь.

Да можно использовать много способов и форматов. У каждого дОцента будет свой.

А с практической точки зрения любая БД (формат не важен, хоть ХМЛ) имеет массу преимуществ. Если мы имеем любой потомок Dataset, то мы сразу можем использовать множество возможностей. В том числе сразу строить дерево, не написав и строчки кода. Т.е. соредоточиться на основной задаче (например на расчете сети), а не отвлекаться на рутину.

Опять же от задачи зависить. Изображать научную деятельность - одно, сделать практически работающую программу - другое.

[Дима_]

Сообщение от ShaggyDoc любая БД (формат не важен, хоть ХМЛ) имеет массу преимуществ.

Это бесспорно, я про то, что структура изначально древовидная, а для нее реляционная БД (mdb) - как у коровы седло - ехать можно, но она (корова) не для этого предназначенна.

[ShaggyDoc]

структура изначально древовидная, а для нее реляционная БД (mdb) - как у коровы седло - ехать можно, но она (корова) не для этого предназначенна

А по этому поводу пущай научно-исследовательские работы пишут, с заголовками " К вопросу о седле для коровы". Пока про это толкуют, практики реляционные БД прекрасно и для деревьев используют. В том числе не для таких ничтожных, как схема вентиляции (максимум несколько десятков строк), но и для очень больших - схема водоснабжения города, например.

[Дима_]

Offtop: Как-то у Вас подозрительно ярко отслеживается ирония в отношении высшего образования. У меня есть два работающих кода делающих одно и то-же - если точнее один - несколько урезанная версия другого, только один (меньший по функционалу - славу богу), в силу физических ограничений сервера именно пришлось писать на "чудесном" PHP. Оба они работают как раз таки с древовидной структурой загруженной в БД (не большой - несколько тысяч записей - автодороги). Так вот этот "меньший" кусочек, как по размеру, так и по трудозатратам на разработку оказался в 20 раз больше, чем больший (административная часть). И все лишь по тому - что последняя сразу загружает всю БД в древовидную структуру и работает с ней (у PHP такой возможности просто нет - да и по скорости без математики СУБД, он-бы просто загнулся - вот и приходилось "извращаться") - если б не "необходимость" использования БД (как единственного "подручного" инструмента PHP дающего необходимую производительность - за счет выполнения вычислений в СУБД) - хрен бы я ее использовал - попробуйте сами, хотя-бы формально, изобразите серию запросов на поиск, например, кратчайшего пути (в задаче, кстати, это было одино из самых простых действий - но и для решения этой ерунды потребовалось создавать временные таблицы в памяти, и городить вокруг них такое, что сам не разберешь как оно работает) - я не знаю может у Вас это и в 1 SQL запрос получится - но сильно сомневаюсь. Я ни каким боком не являюсь "научно-исследовательским" работником, более того - считаю себя как-раз таки "практиком" даже иногда больше чем надо, но однозначно могу сказать - что формат реляционных БД в этих задачах подходит если только для "валовой" загрузки\выгрузки - работать с многовложенными узлами в реляционной БД абсолютное извращение - да занести ее туда просто - основных таблиц всего 2 - графы и "узлы", но работать с ними в этом виде - извращение - и ни из за каких готовых классов быстро и красиво отображающих данные я бы не рекомендовал их к использованию.
з.ы. хотя конечно может быть такой контекст задачи, и 100% понимание что больше от этого дерева ничего не потребуется, который хорошо лег бы на релляционную модель данных - но это частный случай и по крайней мере не про то, про что я сейчас говорю.

[ShaggyDoc]

пришлось писать на "чудесном" PHP

Разве я про PHP писал? Конечно на PHP надо делать всё вручную, там нет "компонентов". Т.е. на написании кода свои силы не сэкономишь. А при использовании соответствующих сред разработки и набора компонетов - очень даже. И весь SQL самый элементарный " select * from ...". Всё остальное сделает компонент. Они есть разные, в том числе позволяющие экономить время на отображении части данных (подкачка по мене необходимости).

Но даже на PHP девовидность прекрасно реализуется. У меня десятка три сайтов, работающих под MODx. MySQL +PHP. В админке сайта его контент отображается деревом. Количество узлов порядка 10000. И никаких тормозов нет. Вот там, в ядре MODx, и потрудились над всем этим. Даже на карту сайта тратится порядка 0.25 сек. А там основное время - прорисовка в браузере. При этом 16 запросов выполняется.

Ну и задачи-то разные. ТС спрашивает про примитивную тупиковую схемку, а Вы рассуждаете про сеть дорог и поиск кратчайшего пути.

Как-то у Вас подозрительно ярко отслеживается ирония в отношении высшего образования

Насмотрелся. На научных руководителей. Я больше 10 лет проработал в управлении информационных технологий Правительства. Есть университет, есть подготовка IT-шников. Есть очень толковые выпускники. Вроде бы и надо поддерживать материально ученых, и гранты есть. Но ничего, приносящего практический результат, они, ученые, сделать не могут. Только рассуждения - "я бы не рекомендовал". Да не нужны нам рекомендации - дайте продукт, как хотите. А продукта нет, одни концепции. Мы несколько раз обжигались, потом перестали. И это при том, что "анкетно" там у них всё прекрасно - публикации, степени, звания...

А вот их студенты, кто имеет стремление и голову, прекрасно со всем справляются. И в практических делах гораздо лучше своих преподавателей. Жаль, мало таких выпускников и работы для них настоящей в наших провинциях мало. Уезжают, и правильно делают.

[Golem-iq]

ShaggyDoc:
Программа по расчёту и отрисовке вентиляции была уже реализовано мною год назад на языке AutoLisp.
Но я так понял я смогу к примеру на языке Delphi (хотя скорее всего это будет C++) с помощью указаных Вами компонентов, создать программку, которая как раз и будет управлять точками в среде AutoCAD.
Научный руководитель есть, но фактически его нет. Ему абсолютно не важно, что я сделать, главное какой-либо результат (вплоть до пояснительной записки с двумя листами: первый титульник, второй библиогрфический список). Но я всё же хотел получить опыт от данной работы.
Дима_:
Поддерживаю вашу идею о XML. Ведь количество ответвлений так теоретически не ограничено. Тем более что в билдере будь то делфи или С++, есть нормальный набор функций для работы с XML-документами и получение значений.

Мне если честно, очень понравилась идея хранить список шагов. А если потом сделать удобную навигацию по дереву с помощью канвы или OpenGL, должно получится довольно прилично.

Завтра иду к научнику, посмотрим, что скажет.
Благодарю за идеи и помощь!