Здравствуйте, UGN, Вы писали:
Al_>>Вопрос в основном математический. Как расчитать полное сопротивление схемы?
Al_>>Ну... потом может как-нибудь рассчитать коэффициент участия каждого сопротивления в импедансе используя эту статистику... (импеданс — полное сопротипление цепи -прим).
Странно, разве импеданс -- это не комплексное число, определяемое активными (сопротивление) и реактивными (емкость) параметрами схемы?
Al_>>Не менее, а может даже и более, интересен вопрос нахождения токов. Здесь можно воспользоваться темже перебором путей, только суммировать при этом сопротивления резисторов на каждом из путей и тд...
UGN>Строишь граф. Считаешь проводимости Y = 1/R UGN>Для токов можешь применить еще и правило Кирхгофа (забыл как правильно пишется)...
Делать надо так: завести по переменной на каждую вершину графа (потенциалы), после чего для заданной пары вершин $i$ и $j$ разность их на данном ребре будет равна $x_j — x_i$. Ток по ребру тогда равен $(x_j-x_i)/R_{ij}$. В каждой вершине (кроме точек подключения источника ЭДС) пишется закон Кирхгофа: алгебраическая сумма токов в вершине равна нулю.
В полученной однородной системе |V| неизвестных и |V|-2 уравнения, чтобы сделать ее определенной нужно принудительно положить в двух вершинах значения потекциалов (0 и какое напряжение подано на схему, например).
Здравствуйте, Al_, Вы писали:
Al_>Вопрос в основном математический. Как расчитать полное сопротивление схемы?
Al_>Ну... потом может как-нибудь рассчитать коэффициент участия каждого сопротивления в импедансе используя эту статистику... (импеданс — полное сопротипление цепи -прим).
Al_>Не менее, а может даже и более, интересен вопрос нахождения токов. Здесь можно воспользоваться темже перебором путей, только суммировать при этом сопротивления резисторов на каждом из путей и тд...
Строишь граф. Считаешь проводимости Y = 1/R
Для токов можешь применить еще и правило Кирхгофа (забыл как правильно пишется)...
Вообще, по этому вопросу есть довольно много литературы...
У меня специальность другая, но в институте чего-то такого немного касались...
Смотри учебники по САПР.
Re[7]: Сопротивление схемы электрических соединений.
Здравствуйте, mab, Вы писали:
mab>Здравствуйте, Al_, Вы писали:
Al_>>Как стороятся графы (: Ты сам спросил! За язык никто не тянул. Теперь рассказывай. mab>Ну тогда встречный вопрос: а как задана схема?
Да вообщем то неважно, там я сам разберусь. Мне только теорию давай, а там уж пережую.(; Насколько я помню составление графов дело не хитрое, хотя может и ошибаюсь.
А вообще то, как было написано в первом письме, — буду строить систему на базе объектно ориентированного программирования, в виде очереди древовидной структуры.
Автоматизация.ERP
Re[12]: Сопротивление схемы электрических соединений.
Здравствуйте, Al_, Вы писали:
Al_>Теперь ясно почему так роете под меня (%. Давно я с графами дело имел и забыл, что он в первую очередь описывается векторами/отрезками, а не массивами чисел (о чем я подразумевал, это и требовал от Вас).
Какими векторами/отрезками? Граф обычно описывается множеством вершин (например, числа 1..N) и ребер (списками смежности/инцидентности, матрицами смежности/инцидентности).
mab>>Сильно... И какой же у этого объекта планируется интерфейс? Al_>Что Вы имеете ввиду?
Ну... если есть объект, то значит все таки он должен реализовать какой-то набор методов, иметь какие-то атрибуты/свойства, как-то влючаться в общую иерархию наследования и т.п. Вроде бы именно это имеют в виду, говоря про ООП. В каком смысле этот термин употреблен у тебя, я до сих пор не понимаю.
Al_>Но насчет "чисто последовательной" Вы зря. Ветви "моего" (уж не знаю как оно в таком случае будет называться) дерева могут и будут замыкаться. С помощью такой структуры вполне можно описать нижеприведеную схему:
Al_> ---000-----000--| Al_> | | Al_>--|--000--|--000--|--000--|-- Al_> | | Al_> |--000-----000--|
Совет дня: лучше использовать моноширинный шрифт для таких картинок, а в Aral-е то сложно что-то увидеть.
Ну ради бога, перестань называть этот ужас деревом, тебя никто не поймет, да еще издеваться будут. В дереве нет циклов, просто по определению.
Это граф произвольного произвольного вида, вряд ли его можно назвать как-то подругому.
mab>>Боюсь, Ваш вопрос совсем не алгоритмический, а скорее технический. Al_>А вот это спорно.
В настоящий момент я не очень понимаю, в чем у тебя проблема. Вроде бы алгоритм изложен достаточно четко. Единственное, что мешает ему быть реализованным -- остуствие формата входных данных. Вот именно его я и называю технической проблемой.
Итак, как и в каком виде данные подаются на вход? Только не надо говорить про ООП и рисовать странные картинки, они сути дела не проясняют.
Al_>PS: Думал на ты с вами (как собс-но и со всеми), но Вы упорно пишете Вы (:
Пофиксено
Re[14]: Сопротивление схемы электрических соединений.
Здравствуйте, Al_, Вы писали:
Al_>Вообщето я это и имел ввиду изначально. То есть как раз составление матриц, описывающих граф. Ты только больше запутал...
Al_>Или, может, ты сомневаешься в необходимости использования ООП... /:
Звучит прямо как "ты за советскую власть?
Все хорошо в меру, тем более что ООП и чистая алгоритмистика иногда вообще не сочетаемые вещи.
По крайней мере я с трудом представляю, как можно пользоваться предложенным интерфейсом.
Al_>
Что такое UprosititiFrom(), GetLastItem(), GetFirstItem()?
Al_>К свойствам в первую очередь относятся Собственый импеданс объекта, затем указатели на рядом находящиеся + еще куча
всего добавится по мере развития.
Что такое "рядом находящиеся"? И что означает "еще куча добавится"? Решать-то задачу нужно сейчас а не потом, вот я и спрашиваю, какой будет интерфейс (уж извини за постоянное употребление этого слова ) через который можно будет о схеме узнать ее структуру? Или предполагается логику вычислений распихать по методам самого класса? Это IHMO тупиковый подход, вот здесь про ООП стоит окончательно и забыть.
Al_>К методам — различные расчетные операции, например перебор путей от одного объекта к другому, посредством рекурентного вызова;
Зачем это нужно?
Al_>Если потребуется, то аналогичным способом составить матрицу инциденции; Затем, возможно, пользовательский интерфейс, для редактирования свойств объекта, да мало ли...
Все это к поставленной задаче прямого отношения не имеет.
Al_>Почему ужас... очень даже гибкая система, позволяющая организовать различные энергосистемы на любом уровне. (Будь то отдельная ВЛ, будь это система электроснабжения города).
Ну прекрасно, может она и дико гибкая, но как можно в ней что-то вычислить я не понимаю.
Al_>А думаешь ложить эти исходные данные на такой алгоритм легко?
Насчет "ложить" не знаю
Вообще же здесь есть ошибка проектирования (с точки зрения ООП): имеем класс, представляющий элемент, а сам контейнер никакому классу не соответствует. На мой взгляд, именно контейнер должен решать вопрос о построении матрицы смежности графа по собственному содержимому.
Re[16]: Сопротивление схемы электрических соединений.
Давай я попробую раз и навсегда прояснить, почему предоложенный "подход" мне кажется довольно абсурдным.
mab>>Звучит прямо как "ты за советскую власть? Al_>(: Почти так и есть. Мне интересен этот подход. Думаю не придется отказываться от него.
Подход, конечно, вещь хорошая, но при неправильном (а точнее, уж прости, неумелом) применении от него страдают все, и в первую очередь -- тот, кто применяет.
Al_>Можно, но со своей спецификой. Вызовы практически всех методов рекурентные, это здорово увеличивает производительость.
Во-первых, скорее уж рекурсивные. Во-вторых, увеличивает по сравнению с чем? Может напомнить пример про вычисление чисел Фибоначчи по реккуррентному соотношению?
В-третьюх: ведь ясно, что число путей в графе между фиксированной парой вершмн может быть экспоненциально велико. Поэтому совсем уж не ясно, о какой производительности идет речь: программа на графе из сотни вершин заснет и уже больше не проснется.
В-четверых: зачем в рамках решаемой задачи это нужно
Al_>>>
mab>>Что такое UprosititiFrom(), GetLastItem(), GetFirstItem()? Al_>Первая, например, упрощает схему, сокращая количество объектов.
Почему тогда это метод класса "резистор"? И чего ему нужно передать в качестве параметра.
Al_>GetFirstItem() — возвращает указатель на самый первый элемент;
Какой-такой самый первый элемент
Al_>GetLastItem() — этот пока ничего, но будет использоваться для перебора путей, ести таковой потребуется.
Это я уже вообще комментировать отказываюсь..
mab>>Что такое "рядом находящиеся"? Al_>...элементы. см. класс.
Смотрю. И офигеваю, потому что вроде бы особым тупизмом обычно не отличаюсь, но сейчас -- хоть убей не понимаю, что к чему.
Al_>Никогда не занимаюсь распределением методов/свойств (кто за что отвечает) до написания кода. Имхо, пустая трата времени.
Может это как-то и называется, но не ООП точно. Потому что в мало-мальски приличной системе такой подход приведет к катастрофе -- будет вноситься заплатка за заплаткой до тех пор, пока никто уже не будет вообще понимать, что происходит.
В столь любимом тобой ООП типична ситуация, когда время на предварительную проработку на порядок больше времени написания кода.
Al_>Лучше написать и наглядно оценить, затем что надо переделать. Может еще блок-схему посоветуешь написать перед началом? /:
Посоветую хорошенько продумать дизайн системы перед тем, как ее писать
Al_>Какую-то часть обязательно распихаю, возможно всю.
И какую же часть? Такое ощущение, что ты думаешь, будто ООП само за тебя это решение примет.
Al_>Посмотрим. Как дойду до дела. Возможно что-то и вынесу за пределы ООП, в чем проблема-то?! тут главное эхотаг продумать (:
Проблема в том, что думать об этом надо сейчас.
Al_>Что? Перебор путей? Да мало-ли что может потребоваться...
О боже...
1) Потребоваться кому?
2) Потребоваться когда?
3) Почему о том, что может потребоваться еще непонятно когда и непонятно зачем ты думаешь сейчас? Или этому учит ООП?
Al_>Расшираемость — вот главное преимущество. А без неё мне и нафиг не нужно (%
Расширяемость -- хорошее средство, но только в предположении, что будет что расширять.
Al_>Можно — можно...
Если не сложно -- приведи пример.
mab>>Вообще же здесь есть ошибка проектирования (с точки зрения ООП): имеем класс, представляющий элемент, а сам контейнер никакому классу не соответствует. На мой взгляд, именно контейнер должен решать вопрос о построении матрицы смежности графа по собственному содержимому. Al_>При желании можно обойтись и без него. Да и создать его всегда можно.
Ну да, я представляю себе: сначала итератор, а потом контейнер. Может это уже преувеличение, но и до этого дойти недолго.
ООП-системы хорошо расширяются "вверх и в сторону", но практически никак -- вниз. Т.е. если в основе будет лежать одна большая ошибка проектирования, то дальше будет полный...м-м... как бы это помягче сказать... крах.
Вообще же дискуссия стала вырождаться. Если у тебя конкретный вопрос -- задай его. Например: как спроектировать такую систему. Тогда можно что-то конкретное сказать, например, что здесь видны такие абстракции, как "схема", "узел сети", "ребро сети". Вообще, лучше это в форуме "Проектирование" спрашивать.
Если есть привязка к C++, то, соответственно, милости просим в соответствующий форум. Только не надо обижаться, если там будут в очень крепких выражениях поминать твой CObject.
С точки зрения computer science объяснено уже все: по схеме строишь систему ЛУ, а потом ее решаешь, например Гауссом. Еще советую обратить внимание на те ссылки, которые тебе дали -- весьма полезно.
Вопрос в основном математический. Как расчитать полное сопротивление схемы?
Предполагается описание схемы на база ООП. Каждый резистор(к примеру) — объект, с определенными связями (пробовал брать за объект узел, но ничего хорошего не придумал).
Какую структуру лучше выбрать? Я рассматривал дерево.
Добрался до следующего:
Сопротивление, ессно, считается относительно 2х точек. Одна из них берется за начальную и перебором по дереву находятся всевозможные пути ко второй точке, при этом ведется статистика количества прохождений через каждый резистр... Дальше не знаю, но по лигике протекания тока вроде пока на верном пути
Ну... потом может как-нибудь рассчитать коэффициент участия каждого сопротивления в импедансе используя эту статистику... (импеданс — полное сопротипление цепи -прим).
Не менее, а может даже и более, интересен вопрос нахождения токов. Здесь можно воспользоваться темже перебором путей, только суммировать при этом сопротивления резисторов на каждом из путей и тд...
Автоматизация.ERP
Re[3]: Сопротивление схемы электрических соединений.
Здравствуйте, mab, Вы писали:
Al_>>>Ну... потом может как-нибудь рассчитать коэффициент участия каждого сопротивления в импедансе используя эту статистику... (импеданс — полное сопротипление цепи -прим). mab>Странно, разве импеданс -- это не комплексное число, определяемое активными (сопротивление) и реактивными (емкость) параметрами схемы?
Мне тоже так показалось, но у него реактивных компонентов нет... Так что сойдет и "импенданс"
UGN>>Для токов можешь применить еще и правило Кирхгофа (забыл как правильно пишется)...
Имелось в виду, что не помню как пишется фамилия...
Re[2]: Сопротивление схемы электрических соединений.
Здравствуйте, UGN, Вы писали:
Al_>>Не менее, а может даже и более, интересен вопрос нахождения токов. Здесь можно воспользоваться темже перебором путей, только суммировать при этом сопротивления резисторов на каждом из путей и тд...
UGN>Строишь граф. Считаешь проводимости Y = 1/R
Ок, надо только вспомнить как это делается. Думаю это не проблема.
UGN>Для токов можешь применить еще и правило Кирхгофа (забыл как правильно пишется)...
Так и пишется (:
UGN>Вообще, по этому вопросу есть довольно много литературы...
То к чему был доступ уже давно перерыл, а в инете ничего толкового нет.
UGN>Смотри учебники по САПР.
Угу, где бы их еще взять. Кроме того ничего подобного не припоминается.
Автоматизация.ERP
Re[3]: Сопротивление схемы электрических соединений.
Здравствуйте, mab, Вы писали:
mab>Странно, разве импеданс -- это не комплексное число, определяемое активными (сопротивление) и реактивными (емкость) параметрами схемы?
В общем случае — да, но для простоты пока рассматривается чисто активное. От этого импеданс не перестаёт быть таковым.
Al_>>>Не менее, а может даже и более, интересен вопрос нахождения токов. Здесь можно воспользоваться темже перебором путей, только суммировать при этом сопротивления резисторов на каждом из путей и тд...
UGN>>Строишь граф. Считаешь проводимости Y = 1/R UGN>>Для токов можешь применить еще и правило Кирхгофа (забыл как правильно пишется)...
mab>Делать надо так: завести по переменной на каждую вершину графа (потенциалы), после чего для заданной пары вершин $i$ и $j$ разность их на данном ребре будет равна $x_j — x_i$. Ток по ребру тогда равен $(x_j-x_i)/R_{ij}$. В каждой вершине (кроме точек подключения источника ЭДС) пишется закон Кирхгофа: алгебраическая сумма токов в вершине равна нулю.
Где здесь минусы, а где подчеркивания?.. или ты имел ввиду заданную пару вершин (x_j,x_i), а не (i,j). Т. к. пары вершин — перебираемые значения, Ы?
PS: Все таки скобки удобнее долларов. /:
mab>В полученной однородной системе |V| неизвестных и |V|-2 уравнения, чтобы сделать ее определенной нужно принудительно положить в двух вершинах значения потекциалов (0 и какое напряжение подано на схему, например).
Кое что понятно (: Осталось только вспомнить теорию графов.
Автоматизация.ERP
Re[4]: Сопротивление схемы электрических соединений.
Здравствуйте, Al_, Вы писали:
mab>>Делать надо так: завести по переменной на каждую вершину графа (потенциалы), после чего для заданной пары вершин $i$ и $j$ разность их на данном ребре будет равна $x_j — x_i$. Ток по ребру тогда равен $(x_j-x_i)/R_{ij}$. В каждой вершине (кроме точек подключения источника ЭДС) пишется закон Кирхгофа: алгебраическая сумма токов в вершине равна нулю. Al_> Где здесь минусы, а где подчеркивания?.. или ты имел ввиду заданную пару вершин (x_j,x_i), а не (i,j). Т. к. пары вершин — перебираемые значения, Ы?
Я имел в виду ровно то, что написал, это TeXовкий способ оформления формул. Минусы -- это обычные минусы, подчеркивания -- это нижние индексы, фигурные скобки -- группировка (например R_{ij} -- это R с двумя нижними индексами: i и j).
Чего-то я не понял про пары вершин Конечно, можно вершины называть по именам переменных (x_i), а не по номерам (i), но какая разница?
Повторю еще раз на словах:
если между вершинами c номерами i и j есть резистор величиной R, то по закону Ома ток через это ребро равен разности потенциалов (x_j — x_i), деленной на R.
Al_> Кое что понятно (: Осталось только вспомнить теорию графов.
Ну так спросите, что конкретно не ясно.
Re[5]: Сопротивление схемы электрических соединений.
Здравствуйте, mab, Вы писали:
mab>>>Делать надо так: завести по переменной на каждую вершину графа (потенциалы), после чего для заданной пары вершин $i$ и $j$ разность их на данном ребре будет равна $x_j — x_i$. Ток по ребру тогда равен $(x_j-x_i)/R_{ij}$. В каждой вершине (кроме точек подключения источника ЭДС) пишется закон Кирхгофа: алгебраическая сумма токов в вершине равна нулю. Al_>> Где здесь минусы, а где подчеркивания?.. или ты имел ввиду заданную пару вершин (x_j,x_i), а не (i,j). Т. к. пары вершин — перебираемые значения, Ы?
mab>Я имел в виду ровно то, что написал, это TeXовкий способ оформления формул. Минусы -- это обычные минусы, подчеркивания -- это нижние индексы, фигурные скобки -- группировка (например R_{ij} -- это R с двумя нижними индексами: i и j).
Понятно. Буду знать.
mab>Чего-то я не понял про пары вершин Конечно, можно вершины называть по именам переменных (x_i), а не по номерам (i), но какая разница?
Я просто не так понял вышеприведенную запись.
Al_>> Кое что понятно (: Осталось только вспомнить теорию графов. mab>Ну так спросите, что конкретно не ясно.
Как стороятся графы (: Ты сам спросил! За язык никто не тянул. Теперь рассказывай.
Автоматизация.ERP
Re[6]: Сопротивление схемы электрических соединений.
Здравствуйте, Al_, Вы писали:
Al_>Как стороятся графы (: Ты сам спросил! За язык никто не тянул. Теперь рассказывай.
Ну тогда встречный вопрос: а как задана схема?
Re[8]: Сопротивление схемы электрических соединений.
Здравствуйте, Al_, Вы писали:
Al_>Да вообщем то неважно, там я сам разберусь. Мне только теорию давай, а там уж пережую.(; Насколько я помню составление графов дело не хитрое, хотя может и ошибаюсь.
Теорию -- про что?? Про составление графов?
Al_>А вообще то, как было написано в первом письме, — буду строить систему на базе объектно ориентированного программирования, в виде очереди древовидной структуры.
Ну тут я пас, поскольку что такое "очередь древовидной структуры" не знаю Как, впрочем, и при чем тут ООП.
Re[9]: Сопротивление схемы электрических соединений.
Здравствуйте, mab, Вы писали:
mab>Здравствуйте, Al_, Вы писали:
Al_>>Да вообщем то неважно, там я сам разберусь. Мне только теорию давай, а там уж пережую.(; Насколько я помню составление графов дело не хитрое, хотя может и ошибаюсь. mab>Теорию -- про что?? Про составление графов?
Вобщето да. Мне только как составить граф.
Al_>>А вообще то, как было написано в первом письме, — буду строить систему на базе объектно ориентированного программирования, в виде очереди древовидной структуры. mab>Ну тут я пас, поскольку что такое "очередь древовидной структуры" не знаю Как, впрочем, и при чем тут ООП.
Разве дерево — не частный случай очереди? Ну ладно... это все терминология. Суть состоит в описании каждого элемента схемы, как объекта (отсюда и ООП), а связи между объектами организуют очередь. Каждый объект будет иметь предыдущий элемент и ряд последующих, образуя дерево.
Если тут напутано с терминологией, то не пинать не стоит.
Автоматизация.ERP
Re[10]: Сопротивление схемы электрических соединений.
Здравствуйте, Al_, Вы писали:
Al_> Вобщето да. Мне только как составить граф.
Могу авторитетно заявить, что в теории графов подобного раздела нет
Al_> Разве дерево — не частный случай очереди?
Жаль огорчать, но нет: очередь -- это структура данных, а дерево -- это связный ациклический граф.
Al_>Ну ладно... это все терминология. Суть состоит в описании каждого элемента схемы, как объекта (отсюда и ООП),
Сильно... И какой же у этого объекта планируется интерфейс?
Al_> а связи между объектами организуют очередь. Каждый объект будет иметь предыдущий элемент и ряд последующих, образуя дерево.
Если схема представляет собой дерево, то зачем вообще огород городить? Ведь последовательнопараллельную (а тут вообще даже чисто последовательную) схему можно рассчитать прямо в лоб.
Боюсь, Ваш вопрос совсем не алгоритмический, а скорее технический.
Al_> Если тут напутано с терминологией, то не пинать не стоит.
И не будем...
Re[11]: Сопротивление схемы электрических соединений.
Здравствуйте, mab, Вы писали:
Al_>> Вобщето да. Мне только как составить граф. mab>Могу авторитетно заявить, что в теории графов подобного раздела нет
(% Да... тяжело с Вами. Если уж на то пошло, то я не говорил, что это является разделом теории графов.
Теперь ясно почему так роете под меня (%. Давно я с графами дело имел и забыл, что он в первую очередь описывается векторами/отрезками, а не массивами чисел (о чем я подразумевал, это и требовал от Вас).
Al_>> Разве дерево — не частный случай очереди? mab>Жаль огорчать, но нет: очередь -- это структура данных, а дерево -- это связный ациклический граф.
Это в рамках тероии графов. Древовидную структуру данных априорно не называют графом.
Al_>>Ну ладно... это все терминология. Суть состоит в описании каждого элемента схемы, как объекта (отсюда и ООП), mab>Сильно... И какой же у этого объекта планируется интерфейс?
Что Вы имеете ввиду?
Al_>> а связи между объектами организуют очередь. Каждый объект будет иметь предыдущий элемент и ряд последующих, образуя дерево. mab>Если схема представляет собой дерево, то зачем вообще огород городить? Ведь последовательнопараллельную (а тут вообще даже чисто последовательную) схему можно рассчитать прямо в лоб.
Да, верно. Матрица никакая не нужна (Для описания графа).
Но насчет "чисто последовательной" Вы зря. Ветви "моего" (уж не знаю как оно в таком случае будет называться) дерева могут и будут замыкаться. С помощью такой структуры вполне можно описать нижеприведеную схему:
Здравствуйте, mab, Вы писали:
Al_>>Теперь ясно почему так роете под меня (%. Давно я с графами дело имел и забыл, что он в первую очередь описывается векторами/отрезками, а не массивами чисел (о чем я подразумевал, это и требовал от Вас). mab>Какими векторами/отрезками? Граф обычно описывается множеством вершин (например, числа 1..N) и ребер (списками смежности/инцидентности, матрицами смежности/инцидентности).
Вообщето я это и имел ввиду изначально. То есть как раз составление матриц, описывающих граф. Ты только больше запутал...
mab>>>Сильно... И какой же у этого объекта планируется интерфейс? Al_>>Что Вы имеете ввиду?
mab>Ну... если есть объект, то значит все таки он должен реализовать какой-то набор методов, иметь какие-то атрибуты/свойства, как-то влючаться в общую иерархию наследования и т.п.
Наследование [пока] здесь непричем. mab>Вроде бы именно это имеют в виду, говоря про ООП. В каком смысле этот термин употреблен у тебя, я до сих пор не понимаю.
В первую очередь, я думаю, имеют ввиду инкапсуляцию. И для этого есть своя терминология. Интерфейс — понятие слишком размытое.
К свойствам в первую очередь относятся Собственый импеданс объекта, затем указатели на рядом находящиеся + еще куча всего добавится по мере развития.
К методам — различные расчетные операции, например перебор путей от одного объекта к другому, посредством рекурентного вызова; Если потребуется, то аналогичным способом составить матрицу инциденции; Затем, возможно, пользовательский интерфейс, для редактирования свойств объекта, да мало ли...
Al_>>Но насчет "чисто последовательной" Вы зря. Ветви "моего" (уж не знаю как оно в таком случае будет называться) дерева могут и будут замыкаться. С помощью такой структуры вполне можно описать нижеприведеную схему:
mab>Совет дня: лучше использовать моноширинный шрифт для таких картинок, а в Aral-е то сложно что-то увидеть.
Уж не знал, что для редактирования и просмотра используются разные шрифты, виноват. /:
mab>Ну ради бога, перестань называть этот ужас деревом, тебя никто не поймет, да еще издеваться будут. В дереве нет циклов, просто по определению.
Почему ужас... очень даже гибкая система, позволяющая организовать различные энергосистемы на любом уровне. (Будь то отдельная ВЛ, будь это система электроснабжения города).
mab>Это граф произвольного произвольного вида, вряд ли его можно назвать как-то подругому.
Вот и прекрасно, на этом и остановимся.
mab>>>Боюсь, Ваш вопрос совсем не алгоритмический, а скорее технический. Al_>>А вот это спорно. mab>В настоящий момент я не очень понимаю, в чем у тебя проблема. Вроде бы алгоритм изложен достаточно четко. Единственное, что мешает ему быть реализованным -- остуствие формата входных данных. Вот именно его я и называю технической проблемой.
А думаешь ложить эти исходные данные на такой алгоритм легко?
mab>Итак, как и в каком виде данные подаются на вход? Только не надо говорить про ООП и рисовать странные картинки, они сути дела не проясняют.
Разве тебе картинка ничего не прояснила? Такие вещи, имхо, проще показывать рисунками. Тогда попробую привести исходный класс.
Здравствуйте, mab, Вы писали:
Al_>>Или, может, ты сомневаешься в необходимости использования ООП... /: mab>Звучит прямо как "ты за советскую власть?
(: Почти так и есть. Мне интересен этот подход. Думаю не придется отказываться от него.
mab>Все хорошо в меру, тем более что ООП и чистая алгоритмистика иногда вообще не сочетаемые вещи. mab>По крайней мере я с трудом представляю, как можно пользоваться предложенным интерфейсом.
Можно, но со своей спецификой. Вызовы практически всех методов рекурентные, это здорово увеличивает производительость.
Al_>>
mab>Что такое UprosititiFrom(), GetLastItem(), GetFirstItem()?
Первая, например, упрощает схему, сокращая количество объектов.
GetFirstItem() — возвращает указатель на самый первый элемент;
GetLastItem() — этот пока ничего, но будет использоваться для перебора путей, ести таковой потребуется.
Al_>>К свойствам в первую очередь относятся Собственый импеданс объекта, затем указатели на рядом находящиеся + еще куча всего добавится по мере развития. mab>Что такое "рядом находящиеся"?
...элементы. см. класс.
mab>И что означает "еще куча добавится"? Решать-то задачу нужно сейчас а не потом,
Никогда не занимаюсь распределением методов/свойств (кто за что отвечает) до написания кода. Имхо, пустая трата времени. Лучше написать и наглядно оценить, затем что надо переделать. Может еще блок-схему посоветуешь написать перед началом? /:
mab> вот я и спрашиваю, какой будет интерфейс (уж извини за постоянное употребление этого слова ) через который можно будет о схеме узнать ее структуру? Или предполагается логику вычислений распихать по методам самого класса?
Какую-то часть обязательно распихаю, возможно всю.
mab> Это IHMO тупиковый подход, вот здесь про ООП стоит окончательно и забыть.
Посмотрим. Как дойду до дела. Возможно что-то и вынесу за пределы ООП, в чем проблема-то?! тут главное эхотаг продумать (:
Al_>>К методам — различные расчетные операции, например перебор путей от одного объекта к другому, посредством рекурентного вызова; mab>Зачем это нужно?
Что? Перебор путей? Да мало-ли что может потребоваться...
Al_>>Если потребуется, то аналогичным способом составить матрицу инциденции; Затем, возможно, пользовательский интерфейс, для редактирования свойств объекта, да мало ли... mab>Все это к поставленной задаче прямого отношения не имеет.
Расшираемость — вот главное преимущество. А без неё мне и нафиг не нужно (%
Al_>>Почему ужас... очень даже гибкая система, позволяющая организовать различные энергосистемы на любом уровне. (Будь то отдельная ВЛ, будь это система электроснабжения города). mab>Ну прекрасно, может она и дико гибкая, но как можно в ней что-то вычислить я не понимаю.
Можно — можно...
Al_>>А думаешь ложить эти исходные данные на такой алгоритм легко? mab>Насчет "ложить" не знаю
(: Ну, блин, юморист. Вполне нормальный словооборот... mab>Вообще же здесь есть ошибка проектирования (с точки зрения ООП): имеем класс, представляющий элемент, а сам контейнер никакому классу не соответствует. На мой взгляд, именно контейнер должен решать вопрос о построении матрицы смежности графа по собственному содержимому.
При желании можно обойтись и без него. Да и создать его всегда можно.
Автоматизация.ERP
Re[16]: Сопротивление схемы электрических соединений.
Здравствуйте, Al_, Вы писали:
Al_>Вчитайтесь плс. Имхо интересно.
Al_>Вопрос в основном математический. Как расчитать полное сопротивление схемы? Al_>Предполагается описание схемы на база ООП. Каждый резистор(к примеру) — объект, с определенными связями (пробовал брать за объект узел, но ничего хорошего не придумал).
Al_>Какую структуру лучше выбрать? Я рассматривал дерево.
Если ты выберешь для представления — не дерево, а граф, то это будет адекватнее.
Простой пример: цепь резисторного моста:
Vcc -> R1, R2
R1 <- Vcc, -> R3, R4
R2 <- Vcc, -> R3 (!!! это уже под-узел другой ветки), R5
...
Конечно, можно решать задачу путем определения участия каждого элемента в цепи. Но это — сурово.
Есть же типовая методика для решения таких задач.
Итак, граф цепи. Элементы — это ребра между узлами (точками коммутации).
1) в электрической цепи разделяют:
— источники напряжения (бесконечное сопротивление — разрыв)
— источники тока (нулевое сопротивление — КЗ)
— чисто активные/реактивные элементы.
Будем надеяться, что в цепи нет нелинейных элементов.
Если есть реактивные — будем иметь дело с комплексными числами, если нет — с вещественными.
2) Исключаем все источники, заменяя их на активные элементы (КЗ и разрывы).
3) Полученный граф будем последовательно упрощать.
* ребра-разрывы — выбрасываем
* ребра-коротыши — стягиваем две вершины в одну, ребро выбрасываем
* ребра-петли — выбрасываем (эту операцию, возможно, еще придется повторить).
Далее будем повторять:
* если к вершине (кроме полюсов) нет ребер — удаляем ее.
* если к вершине (кроме полюсов) подходит одно ребро — это обрыв — удаляем вершину и ребро.
* если к вершине (кроме полюсов) подходят два ребра — это последовательное соединение — вершину удаляем, ребра заменяем на одно.
* если ребро подходит к одной и той же вершине — это петля — удаляем его.
* если к двум вершинам подходят несколько ребер — это параллельное соединение — заменяем ребра на одно.
* наконец, если три ребра образуют треугольник — заменяем его на звезду (удаляем ребра, добавляем новую вершину и три новых ребра к вершинам треугольника).
Продолжаем, пока есть что упрощать.
В результате остаются два полюса и ребро между ними. Его сопротивление и есть сопротивление цепи.
Внешне — кажется, что алгоритм непродуктивен (постоянно занимаемся перебором всех вершин и ребер).
Однако он с легкостью поддается оптимизации.
Заводится список/множество нерассмотренных ребер и вершин; изначально в этом списке — все-все-все.
Из него вынимаем первую попавшуюся вершину и исследуем ее.
Если в результате у этой вершины изменились ребра — вновь помещаем ее в список.
Аналогично — с ребрами. Кроме того, когда мы добавляем вершину (по правилу треугольник-звезда) — тоже помещаем ее в список.
Список может быть с приоритетами: вершины отсортированы по числу ребер (сперва нули, затем одиночные, затем последовательности, затем все остальные).
Как представить такой граф — это уже интересная задача.
Объект ребро — атрибут: сопротивление; две вершины.
Объект вершина — множество ребер.
Объект граф — множество вершин (и, как объединение всех вершин — множество ребер).
Перекуём баги на фичи!
Re[2]: Сопротивление схемы электрических соединений.
Здравствуйте, Кодт, Вы писали:
К>Продолжаем, пока есть что упрощать. К>В результате остаются два полюса и ребро между ними. Его сопротивление и есть сопротивление цепи.
Не очень понял: разве не бывает графов без треугольников, кратных ребер и вершин степени два??
Вроде бы указанные редукции к ним уже не применимы.
Re[3]: Сопротивление схемы электрических соединений.
Здравствуйте, mab, Вы писали:
mab>Здравствуйте, Кодт, Вы писали:
К>>Продолжаем, пока есть что упрощать. К>>В результате остаются два полюса и ребро между ними. Его сопротивление и есть сопротивление цепи. mab>Не очень понял: разве не бывает графов без треугольников, кратных ребер и вершин степени два?? mab>Вроде бы указанные редукции к ним уже не применимы.
Бывают, бывают. Например, куб.
Я уже ТОЭ в достаточной мере забыл, чтобы вспомнить, как разруливаются циклы. Как-то это делается...
Все равно там переход от цикла к звезде.
Перекуём баги на фичи!
Re[4]: Сопротивление схемы электрических соединений.
Здравствуйте, Кодт, Вы писали:
К>Я уже ТОЭ в достаточной мере забыл, чтобы вспомнить, как разруливаются циклы. Как-то это делается... К>Все равно там переход от цикла к звезде.
А чем все-таки методы узловых потенциалов или, например, контурных токов плохи? Вроде бы составляешь систему и вперед.. Главное -- думать не надо
Re[17]: Сопротивление схемы электрических соединений.
Здравствуйте, mab, Вы писали:
mab>Давай я попробую раз и навсегда прояснить, почему предоложенный "подход" мне кажется довольно абсурдным. mab>>>Звучит прямо как "ты за советскую власть? Al_>>(: Почти так и есть. Мне интересен этот подход. Думаю не придется отказываться от него.
Al_>>Можно, но со своей спецификой. Вызовы практически всех методов рекурентные, это здорово увеличивает производительость. mab>Во-первых, скорее уж рекурсивные.
Я думал это одно и тоже. /: mab>Во-вторых, увеличивает по сравнению с чем?
Если говорить в рамках поставленой задачи, то не знаю (скорее всего матричный метод). А вообще... помнишь, ставший уже классический пример с вычислением факториала?
mab>Может напомнить пример про вычисление чисел Фибоначчи по реккуррентному соотношению?
Милости просим, если не затруднит. С удовольствием посмотрю.
mab>В-третьюх: ведь ясно, что число путей в графе между фиксированной парой вершмн может быть экспоненциально велико. Поэтому совсем уж не ясно, о какой производительности идет речь: программа на графе из сотни вершин заснет и уже больше не проснется.
Поговорим об этом, когда дойду до конкретной реализации.
mab>В-четверых: зачем в рамках решаемой задачи это нужно
Смотри.
class CObject
{
public:
BOOL CurrentIsCalculated; // при изменении структуры эти зачения
BOOL EndNodePotentialCalculated; // должны обнулитьсяdouble Current; // Здесь хранится выч. значение токаdouble EndPotential; // ...значение потенциала
CObject();
CObject(double dImpedans);
virtual ~CObject();
CObject *pPrevItem;
CQueue *pNextItems;
CObject *GetFirstObject();
void AppendNextItemsToQueue(CQueue *pQueue);
double Impedans; // Сопротивление объектаdouble CalculateCurrent(); // Вычисляет ток, протекающий по объекту
// по соотношению 1-го правила Кирхгоффа.double VoltageFall(); // Падение напряжения на объектеdouble EndNodePotential(); // Потенциал в узле за объектом
};
class CCircuitry
{
BOOL StructureChanged; // Флаг изменения схемыpublic:
CCircuitry();
~CCircuitry();
CObject *FirstObject;
CObject *AddObjectTo(CObject *pObject, double dImpedans);
//* Установка исходных данныхvoid SetEndNodePotential(CObject *pObject, double dPotential);
};
Al_>>GetFirstItem() — возвращает указатель на самый первый элемент; mab>Какой-такой самый первый элемент
Смотри сам.
Этото значение потребовалось в CalculateCurrent() сбора всех объектов схемы в одну очередь, чтоб затем их можно было перебрать.
В реализации CalculateCurrent() есть один момент, так что пока не проси привести его.
mab>>>Что такое "рядом находящиеся"? Al_>>...элементы. см. класс. mab>Смотрю. И офигеваю, потому что вроде бы особым тупизмом обычно не отличаюсь, но сейчас -- хоть убей не понимаю, что к чему. mab>
)% А вот эти разве под это описание не подходят?!
CObject *pPrevItem;
CQueue *pNextItems;
Al_>>Никогда не занимаюсь распределением методов/свойств (кто за что отвечает) до написания кода. Имхо, пустая трата времени. mab>Может это как-то и называется, но не ООП точно. Потому что в мало-мальски приличной системе такой подход приведет к катастрофе -- будет вноситься заплатка за заплаткой до тех пор, пока никто уже не будет вообще понимать, что происходит.
/: спасибо за критику. Пока краха ниразу не снучалось.
mab>В столь любимом тобой ООП типична ситуация, когда время на предварительную проработку на порядок больше времени написания кода.
Полностью с тобой соглласен, но в здесь, на работе, у меня нет возможности "предварительно прорабатывать", а то что я тут пишу мало заметно... поэтому тыкаемся, тыкаемся... За выходные я немного продвинулся...
Al_>>Лучше написать и наглядно оценить, затем что надо переделать. Может еще блок-схему посоветуешь написать перед началом? /: mab>Посоветую хорошенько продумать дизайн системы перед тем, как ее писать
Ты будешь смеяться, но я еше толком методику не выбрал, а от нее много что зависит. но ты мне уже помог. За это тебе спасибо.
Al_>>Какую-то часть обязательно распихаю, возможно всю. mab>И какую же часть? Такое ощущение, что ты думаешь, будто ООП само за тебя это решение примет.
Как потребуется, так и решу.
Al_>>Посмотрим. Как дойду до дела. Возможно что-то и вынесу за пределы ООП, в чем проблема-то?! тут главное эхотаг продумать (: mab>Проблема в том, что думать об этом надо сейчас.
Все все равно не предусмотришь.
Al_>>Что? Перебор путей? Да мало-ли что может потребоваться... mab>О боже... mab>1) Потребоваться кому? mab>2) Потребоваться когда? mab>3) Почему о том, что может потребоваться еще непонятно когда и непонятно зачем ты думаешь сейчас? Или этому учит ООП?
Al_>>Можно — можно... mab>Если не сложно -- приведи пример.
mab>>>Вообще же здесь есть ошибка проектирования (с точки зрения ООП): имеем класс, представляющий элемент, а сам контейнер никакому классу не соответствует. На мой взгляд, именно контейнер должен решать вопрос о построении матрицы смежности графа по собственному содержимому. Al_>>При желании можно обойтись и без него. Да и создать его всегда можно. mab>Ну да, я представляю себе: сначала итератор, а потом контейнер. Может это уже преувеличение, но и до этого дойти недолго.
Уже сдалал (см. выше) и, вроде никто от этого не умер. Ы?
mab>Вообще же дискуссия стала вырождаться. Если у тебя конкретный вопрос -- задай его. Например: как спроектировать такую систему. Тогда можно что-то конкретное сказать, например, что здесь видны такие абстракции, как "схема", "узел сети", "ребро сети".
Вот конкретный вопрос:
Теорема: Ток, протекающий по объекту, равен сумме токов объектов NextItems,
за вычетом токов объектов, для которых очередь NextItems такаяже как у "этого" объекта.
На основании этого расчитывается ток объекта.
mab>Вообще, лучше это в форуме "Проектирование" спрашивать.
MB
mab>Если есть привязка к C++, то, соответственно, милости просим в соответствующий форум. Только не надо обижаться, если там будут в очень крепких выражениях поминать твой CObject.
Ну думаю, что сейчас уже не такими крепкими (как видишь, там кое что переделал).
mab>С точки зрения computer science объяснено уже все: по схеме строишь систему ЛУ, а потом ее решаешь, например Гауссом. Еще советую обратить внимание на те ссылки, которые тебе дали -- весьма полезно.
Да. Сразу посмотрел и куда надо сохранил. Но пока на уме немного другая методика. Сейчас, к сожалению, уже нет времени писать. В следующем письме.
Автоматизация.ERP
Re[2]: Сопротивление схемы электрических соединений.
Здравствуйте, Кодт, Вы писали:
Al_>>Вопрос в основном математический. Как расчитать полное сопротивление схемы? Al_>>Предполагается описание схемы на база ООП.
К>Если ты выберешь для представления — не дерево, а граф, то это будет адекватнее. К>Простой пример: цепь резисторного моста: К>
К>Vcc -> R1, R2
К>R1 <- Vcc, -> R3, R4
К>R2 <- Vcc, -> R3 (!!! это уже под-узел другой ветки), R5
К>
Как мне сказали, это немножно не дерево (: но у меня это реализовано следующим образом:
Vcc -> R1, R2;
R1 <- Vcc; -> R3, R4
R2 <- Vcc; -> R5 (R3 второй раз не включается, он следующий элемент только для R1).
R3 <- R1; -> R5
R4 <- R1; -> End
R5 <- R2; -> End
К>Конечно, можно решать задачу путем определения участия каждого элемента в цепи. Но это — сурово.
Согласен. Уже отказался от этого.
К>Есть же типовая методика для решения таких задач. К>Итак, граф цепи. Элементы — это ребра между узлами (точками коммутации).
К>1) в электрической цепи разделяют: К>- источники напряжения (бесконечное сопротивление — разрыв) К>- источники тока (нулевое сопротивление — КЗ) К>- чисто активные/реактивные элементы.
Для начала упростим задачу, используя только активные элементы. Крайности, имхо, можно учесть и потом.
К>Будем надеяться, что в цепи нет нелинейных элементов.
Потом будут (: Сначала надо эту решить.
К>Если есть реактивные — будем иметь дело с комплексными числами, если нет — с вещественными.
Только вещественные.
К>2) Исключаем все источники, заменяя их на активные элементы (КЗ и разрывы).
К>3) Полученный граф будем последовательно упрощать.
К>* ребра-разрывы — выбрасываем
Это те, которые тольо одним концом присоеденены к узлу?
К>* ребра-коротыши — стягиваем две вершины в одну, ребро выбрасываем
Я, так понимаю, это с нулевым сопротивлением...
К>* ребра-петли — выбрасываем (эту операцию, возможно, еще придется повторить).
Оба конца — к одному узлу?
Я, выше, все уточнил, чтоб не было путаницы.
Все верно?
К>Далее будем повторять: К>* если к вершине (кроме полюсов) нет ребер — удаляем ее. К>* если к вершине (кроме полюсов) подходит одно ребро — это обрыв — удаляем вершину и ребро. К>* если к вершине (кроме полюсов) подходят два ребра — это последовательное соединение — вершину удаляем, ребра заменяем на одно. К>* если ребро подходит к одной и той же вершине — это петля — удаляем его. К>* если к двум вершинам подходят несколько ребер — это параллельное соединение — заменяем ребра на одно. К>* наконец, если три ребра образуют треугольник — заменяем его на звезду (удаляем ребра, добавляем новую вершину и три новых ребра к вершинам треугольника).
К>Продолжаем, пока есть что упрощать. К>В результате остаются два полюса и ребро между ними. Его сопротивление и есть сопротивление цепи.
Все понятно. А есть 100% гарантия, того что останется одно ребро и 2 вершины? Если да, тогда я просто рад (: К>Внешне — кажется, что алгоритм непродуктивен (постоянно занимаемся перебором всех вершин и ребер).
Отнюдь. Или, что ты подразумеваешь под непродуктивностью?..
К>Однако он с легкостью поддается оптимизации. К>Заводится список/множество нерассмотренных ребер и вершин; изначально в этом списке — все-все-все. К>Из него вынимаем первую попавшуюся вершину и исследуем ее. К>Если в результате у этой вершины изменились ребра — вновь помещаем ее в список. К>Аналогично — с ребрами. Кроме того, когда мы добавляем вершину (по правилу треугольник-звезда) — тоже помещаем ее в список. К>Список может быть с приоритетами: вершины отсортированы по числу ребер (сперва нули, затем одиночные, затем последовательности, затем все остальные).
Ок! (:
Единственное — интересны, также, токи по каждому ребру. Но как алгоритм упрощения он весьма и весьма превлекателен.
А нелинейные элементы надо выность за пределы такого упрощения.
К> К>Как представить такой граф — это уже интересная задача.
Вот оно! Самое интересное.
К>Объект ребро — атрибут: сопротивление; две вершины. К>Объект вершина — множество ребер. К>Объект граф — множество вершин (и, как объединение всех вершин — множество ребер).
Спасибо.
Автоматизация.ERP
Re[3]: Сопротивление схемы электрических соединений.
К>>Как здесь организовать дерево? Al_>Как мне сказали, это немножно не дерево (: но у меня это реализовано следующим образом: Al_>
Al_>Vcc -> R1, R2;
Al_>R1 <- Vcc; -> R3, R4
Al_>R2 <- Vcc; -> R5 (R3 второй раз не включается, он следующий элемент только для R1).
Al_>R3 <- R1; -> R5
Al_>R4 <- R1; -> End
Al_>R5 <- R2; -> End
Al_>
Al_>
То есть из графа схемы ты делаешь орграф:
— у каждого ребра есть вершина-исток и вершина-сток
— список ребер, выходящих из стока, хранится в списке "следующие элементы"
— исток идентифицирован стоком "предыдущего" элемента
Почему бы в модели сразу не разделить объекты:
— вершины (клеммы)
— ребра (элементы)
Основное свойство клеммы — это потенциал; свойство элемента — сопротивление (и, как следствие разности потенциалов — ток).
При этом становится несущественно, где у элемента перед, а где зад. (В твоей модели — существенно).
Как выберешь, так и хрен с ним.
Опять же, ввод модели упрощается: просто указываешь множество клемм, и дальше — список элементов (клемма,клемма,сопротивление).
Нет нужды вводить фиктивные элементы Vcc, Vgnd.
К>>* ребра-разрывы — выбрасываем Al_>Это те, которые тольо одним концом присоеденены к узлу?
Разрыв — это элемент с бесконечным сопротивлением.
К>>* ребра-коротыши — стягиваем две вершины в одну, ребро выбрасываем Al_>Я, так понимаю, это с нулевым сопротивлением...
Да.
Я их перечислил для полноты картины (поскольку КЗ и ХХ возникают при удалении источников тока и напряжения).
К>>* ребра-петли — выбрасываем (эту операцию, возможно, еще придется повторить). Al_>Оба конца — к одному узлу?
Да.
К>>Продолжаем, пока есть что упрощать. К>>В результате остаются два полюса и ребро между ними. Его сопротивление и есть сопротивление цепи. Al_>Все понятно. А есть 100% гарантия, того что останется одно ребро и 2 вершины? Если да, тогда я просто рад (:
Если мы умеем уничтожать циклы (превращая их в звезды) — то, без сомнения. Это легко доказать по индукции.
Al_> К>>Внешне — кажется, что алгоритм непродуктивен (постоянно занимаемся перебором всех вершин и ребер). Al_>Отнюдь. Или, что ты подразумеваешь под непродуктивностью?..
Имел в виду, что при сокращениях приходится постоянно сканировать граф. При тупой реализации — это исключительно долгое занятие (порядка O(N^3), если я не путаю).
К>> К>>Как представить такой граф — это уже интересная задача. Al_>Вот оно! Самое интересное.
Остаюсь при своем имхо, что вершины и ребра — это разные объекты (и агрегировать друг в друга не нужно).
Как сохранить при сокращениях информацию о токе через каждый элемент? Очень просто.
Каждый раз, удаляя элемент, мы не забываем его, а помечаем как выбывший.
Новые "эффективные" элементы помечаем, как вошедшие.
Клеммы мы тоже не забываем...
В результате получаем такую модель: Vcc -- R -- Gnd
Ток нам известен.
Если R — это замена последовательного соединения, то восстанавливаем клеммы и напряжения на них по току;
если параллельное — то токи по напряжению;
если звезда — то по страшной формуле.
Продолжаем, пока не останется эффективных элементов.
Перекуём баги на фичи!
Re[4]: Сопротивление схемы электрических соединений.
Здравствуйте, Кодт, Вы писали:
Al_>>Как мне сказали, это немножно не дерево (: но у меня это реализовано следующим образом: Al_>>
Al_>>Vcc -> R1, R2;
Al_>>R1 <- Vcc; -> R3, R4
Al_>>R2 <- Vcc; -> R5 (R3 второй раз не включается, он следующий элемент только для R1).
Al_>>R3 <- R1; -> R5
Al_>>R4 <- R1; -> End
Al_>>R5 <- R2; -> End
Al_>>
К>То есть из графа схемы ты делаешь орграф: К>- у каждого ребра есть вершина-исток и вершина-сток К>- список ребер, выходящих из стока, хранится в списке "следующие элементы" К>- исток идентифицирован стоком "предыдущего" элемента
Верно. Посмотри на объект:
class CObject
{
public:
BOOL CurrentIsCalculated; // при изменении структуры эти зачения
BOOL EndNodePotentialCalculated; // должны обнулитьсяdouble Current; // Здесь хранится выч. значение токаdouble EndPotential; // ...значение потенциала
CObject(double dImpedans);
virtual ~CObject();
/* Вот они, родные */
CObject *pPrevObject;
CQueue *pNextObjects;
CObject *GetFirstObject();
/* Нужно для "переброса" всех объектов в одну очередь, чтоб потом их можно было безболезнено перебирать. См. метод CCircuitry::CollectAllObjects(CQueue **pAllObjects) ниже */void AppendNextItemsToQueue(CQueue *pQueue);
double Impedans; // Сопротивление объектаdouble CalculateCurrent(); // Вычисляет ток, протекающий по объектуdouble VoltageFall(); // Падение напряжения на объектеdouble EndNodePotential(); // Потенциал в узле за объектом
};
К>Почему бы в модели сразу не разделить объекты: К>- вершины (клеммы) К>- ребра (элементы)
А что это даст?
К>Основное свойство клеммы — это потенциал; свойство элемента — сопротивление (и, как следствие разности потенциалов — ток). К>При этом становится несущественно, где у элемента перед, а где зад. К>(В твоей модели — существенно).
Да, это нарушает логику... но пока при работе с такой системой я сталкивался с одними плюсами (: Посмотри ниже как легко она упрощается.
К>Опять же, ввод модели упрощается: просто указываешь множество клемм, и дальше — список элементов (клемма,клемма,сопротивление).
Ввод организован следующим образом: задаешь элемент, и к нему в список Next'ов добавляется новый. Легко и просто. Все это делает метод CCircuitry::AddObjectTo(CObject *pObject, double dImpedans).
А вот и схема:
class CCircuitry
{
BOOL StructureChanged; // Флаг изменения схемыpublic:
CCircuitry();
~CCircuitry();
/* Корень "дерева" */
CObject *FirstObject;
CObject *AddObjectTo(CObject *pObject, double dImpedans);
/* Собирает в одну очередь все элементы схемы */void CollectAllObjects(CQueue **pAllObjects);
/* Упрощение схемы по предложенному тобой алгоритму (реализация ниже)*/void SchemeSimplification();
void DeleteObject(CObject *pObject);
// Установка исходных данныхvoid SetEndNodePotential(CObject *pObject, double dPotential);
};
К>Нет нужды вводить фиктивные элементы Vcc, Vgnd.
А я и не ввожу.
Для Vcc и Vgnd просто задаётся значение EndNodePotentialCalculated=TRUE и, соответственно, EndPotential=const.
К>>>* ребра-разрывы — выбрасываем Al_>>Это те, которые тольо одним концом присоеденены к узлу?
К>Разрыв — это элемент с бесконечным сопротивлением.
К>>>* ребра-коротыши — стягиваем две вершины в одну, ребро выбрасываем Al_>>Я, так понимаю, это с нулевым сопротивлением... К>Да.
К>Я их перечислил для полноты картины (поскольку КЗ и ХХ возникают при удалении источников тока и напряжения).
К>>>* ребра-петли — выбрасываем (эту операцию, возможно, еще придется повторить). Al_>>Оба конца — к одному узлу? К>Да.
Вот так просто это все выглядит:
// Рёбра-разрывы выбрасываютсяif (!pObject->pNextObjects) if (!pObject->EndNodePotentialCalculated)
{
DeleteObject(pObject);
break;
}
// Рёбра-петли выбрасываютсяif (pObject->pNextObjects->FindByData(pObject->pPrevObject))
{
DeleteObject(pObject);
break;
}
// Ребра-коротыши: стягиваются две вершины в одну, ребро выбрасываетсяif (!pObject->Impedans)
{
DeleteObject(pObject);
break;
}
// Последовательное соединение:if (pObject->pNextObjects)
{
if (!pObject->EndNodePotentialCalculated) // Узел не должен запитываться.
{
CObject *pSecondObject;
pObject->pNextObjects->ChoiseItems(); // Открывается выборка след. эл-товif (pSecondObject=(CObject*)pObject->pNextObjects->SelectFromChoise())
if (!pObject->pNextObjects->SelectNextFromChoise())
{
// То есть в выборке только 1 элемент
pObject->Impedans += pSecondObject->Impedans;
DeleteObject(pSecondObject);
break;
}
}
}
К>Если мы умеем уничтожать циклы (превращая их в звезды) — то, без сомнения. Это легко доказать по индукции.
Если цикл не внёс именения в схему — значит завис ==> Принимаем меры...
Al_>> К>>>Внешне — кажется, что алгоритм непродуктивен (постоянно занимаемся перебором всех вершин и ребер). Al_>>Отнюдь. Или, что ты подразумеваешь под непродуктивностью?..
К>Имел в виду, что при сокращениях приходится постоянно сканировать граф. При тупой реализации — это исключительно долгое занятие (порядка O(N^3), если я не путаю).
Возможно. Как там говорится "оптимизация на этапе разработки — корень зла в программировании". Доживем увидим.
К>Остаюсь при своем имхо, что вершины и ребра — это разные объекты (и агрегировать друг в друга не нужно).
Сначаля добью свою методику, потом помотрим.
К>Как сохранить при сокращениях информацию о токе через каждый элемент? Очень просто. К>Каждый раз, удаляя элемент, мы не забываем его, а помечаем как выбывший. К>Новые "эффективные" элементы помечаем, как вошедшие. К>Клеммы мы тоже не забываем...
К>В результате получаем такую модель: Vcc -- R -- Gnd К>Ток нам известен. К>Если R — это замена последовательного соединения, то восстанавливаем клеммы и напряжения на них по току; К>если параллельное — то токи по напряжению; К>если звезда — то по страшной формуле.
(: У меня есть одно предложение, как вообще обойтись без сворачивания.
Т.н. ООП-метод решения системы уравнений.