Вчитайтесь плс. Имхо интересно.

Вопрос в основном математический. Как расчитать полное сопротивление схемы?
Предполагается описание схемы на база ООП. Каждый резистор(к примеру) — объект, с определенными связями (пробовал брать за объект узел, но ничего хорошего не придумал).

Какую структуру лучше выбрать? Я рассматривал дерево.

Добрался до следующего:
Сопротивление, ессно, считается относительно 2х точек. Одна из них берется за начальную и перебором по дереву находятся всевозможные пути ко второй точке, при этом ведется статистика количества прохождений через каждый резистр... Дальше не знаю, но по лигике протекания тока вроде пока на верном пути

Ну... потом может как-нибудь рассчитать коэффициент участия каждого сопротивления в импедансе используя эту статистику... (импеданс — полное сопротипление цепи -прим).

Не менее, а может даже и более, интересен вопрос нахождения токов. Здесь можно воспользоваться темже перебором путей, только суммировать при этом сопротивления резисторов на каждом из путей и тд...

Здравствуйте, Al_, Вы писали:

Al_>Вопрос в основном математический. Как расчитать полное сопротивление схемы?

Al_>Ну... потом может как-нибудь рассчитать коэффициент участия каждого сопротивления в импедансе используя эту статистику... (импеданс — полное сопротипление цепи -прим).

Al_>Не менее, а может даже и более, интересен вопрос нахождения токов. Здесь можно воспользоваться темже перебором путей, только суммировать при этом сопротивления резисторов на каждом из путей и тд...

Строишь граф. Считаешь проводимости Y = 1/R

Для токов можешь применить еще и правило Кирхгофа (забыл как правильно пишется)...

Вообще, по этому вопросу есть довольно много литературы...

У меня специальность другая, но в институте чего-то такого немного касались...

Смотри учебники по САПР.

Здравствуйте, 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 и какое напряжение подано на схему, например).

Здравствуйте, mab, Вы писали:

Al_>>>Ну... потом может как-нибудь рассчитать коэффициент участия каждого сопротивления в импедансе используя эту статистику... (импеданс — полное сопротипление цепи -прим).
mab>Странно, разве импеданс -- это не комплексное число, определяемое активными (сопротивление) и реактивными (емкость) параметрами схемы?

Мне тоже так показалось, но у него реактивных компонентов нет... Так что сойдет и "импенданс"

UGN>>Для токов можешь применить еще и правило Кирхгофа (забыл как правильно пишется)...

Имелось в виду, что не помню как пишется фамилия...

Здравствуйте, UGN, Вы писали:

Al_>>Не менее, а может даже и более, интересен вопрос нахождения токов. Здесь можно воспользоваться темже перебором путей, только суммировать при этом сопротивления резисторов на каждом из путей и тд...

UGN>Строишь граф. Считаешь проводимости Y = 1/R
Ок, надо только вспомнить как это делается. Думаю это не проблема.

UGN>Для токов можешь применить еще и правило Кирхгофа (забыл как правильно пишется)...
Так и пишется (:

UGN>Вообще, по этому вопросу есть довольно много литературы...
То к чему был доступ уже давно перерыл, а в инете ничего толкового нет.

UGN>Смотри учебники по САПР.
Угу, где бы их еще взять. Кроме того ничего подобного не припоминается.

Здравствуйте, 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 и какое напряжение подано на схему, например).
Кое что понятно (: Осталось только вспомнить теорию графов.

Здравствуйте, 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_> Кое что понятно (: Осталось только вспомнить теорию графов.
Ну так спросите, что конкретно не ясно.

Здравствуйте, 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>Ну так спросите, что конкретно не ясно.
Как стороятся графы (: Ты сам спросил! За язык никто не тянул. Теперь рассказывай.

Здравствуйте, Al_, Вы писали:

Al_>Как стороятся графы (: Ты сам спросил! За язык никто не тянул. Теперь рассказывай.
Ну тогда встречный вопрос: а как задана схема?

Здравствуйте, mab, Вы писали:

mab>Здравствуйте, Al_, Вы писали:

Al_>>Как стороятся графы (: Ты сам спросил! За язык никто не тянул. Теперь рассказывай.
mab>Ну тогда встречный вопрос: а как задана схема?
Да вообщем то неважно, там я сам разберусь. Мне только теорию давай, а там уж пережую.(; Насколько я помню составление графов дело не хитрое, хотя может и ошибаюсь.

А вообще то, как было написано в первом письме, — буду строить систему на базе объектно ориентированного программирования, в виде очереди древовидной структуры.

Здравствуйте, Al_, Вы писали:

Al_>Да вообщем то неважно, там я сам разберусь. Мне только теорию давай, а там уж пережую.(; Насколько я помню составление графов дело не хитрое, хотя может и ошибаюсь.
Теорию -- про что?? Про составление графов?

Al_>А вообще то, как было написано в первом письме, — буду строить систему на базе объектно ориентированного программирования, в виде очереди древовидной структуры.
Ну тут я пас, поскольку что такое "очередь древовидной структуры" не знаю Как, впрочем, и при чем тут ООП.

Здравствуйте, mab, Вы писали:

mab>Здравствуйте, Al_, Вы писали:

Al_>>Да вообщем то неважно, там я сам разберусь. Мне только теорию давай, а там уж пережую.(; Насколько я помню составление графов дело не хитрое, хотя может и ошибаюсь.
mab>Теорию -- про что?? Про составление графов?
Вобщето да. Мне только как составить граф.

Al_>>А вообще то, как было написано в первом письме, — буду строить систему на базе объектно ориентированного программирования, в виде очереди древовидной структуры.
mab>Ну тут я пас, поскольку что такое "очередь древовидной структуры" не знаю Как, впрочем, и при чем тут ООП.
Разве дерево — не частный случай очереди? Ну ладно... это все терминология. Суть состоит в описании каждого элемента схемы, как объекта (отсюда и ООП), а связи между объектами организуют очередь. Каждый объект будет иметь предыдущий элемент и ряд последующих, образуя дерево.
Если тут напутано с терминологией, то не пинать не стоит.

Здравствуйте, Al_, Вы писали:

Al_> Вобщето да. Мне только как составить граф.
Могу авторитетно заявить, что в теории графов подобного раздела нет

Al_> Разве дерево — не частный случай очереди?
Жаль огорчать, но нет: очередь -- это структура данных, а дерево -- это связный ациклический граф.

Al_>Ну ладно... это все терминология. Суть состоит в описании каждого элемента схемы, как объекта (отсюда и ООП),
Сильно... И какой же у этого объекта планируется интерфейс?

Al_> а связи между объектами организуют очередь. Каждый объект будет иметь предыдущий элемент и ряд последующих, образуя дерево.
Если схема представляет собой дерево, то зачем вообще огород городить? Ведь последовательнопараллельную (а тут вообще даже чисто последовательную) схему можно рассчитать прямо в лоб.

Боюсь, Ваш вопрос совсем не алгоритмический, а скорее технический.

Al_> Если тут напутано с терминологией, то не пинать не стоит.
И не будем...

Здравствуйте, mab, Вы писали:

Al_>> Вобщето да. Мне только как составить граф.
mab>Могу авторитетно заявить, что в теории графов подобного раздела нет
(% Да... тяжело с Вами. Если уж на то пошло, то я не говорил, что это является разделом теории графов.
Теперь ясно почему так роете под меня (%. Давно я с графами дело имел и забыл, что он в первую очередь описывается векторами/отрезками, а не массивами чисел (о чем я подразумевал, это и требовал от Вас).

Al_>> Разве дерево — не частный случай очереди?
mab>Жаль огорчать, но нет: очередь -- это структура данных, а дерево -- это связный ациклический граф.
Это в рамках тероии графов. Древовидную структуру данных априорно не называют графом.

Al_>>Ну ладно... это все терминология. Суть состоит в описании каждого элемента схемы, как объекта (отсюда и ООП),
mab>Сильно... И какой же у этого объекта планируется интерфейс?
Что Вы имеете ввиду?

Al_>> а связи между объектами организуют очередь. Каждый объект будет иметь предыдущий элемент и ряд последующих, образуя дерево.
mab>Если схема представляет собой дерево, то зачем вообще огород городить? Ведь последовательнопараллельную (а тут вообще даже чисто последовательную) схему можно рассчитать прямо в лоб.

Да, верно. Матрица никакая не нужна (Для описания графа).
Но насчет "чисто последовательной" Вы зря. Ветви "моего" (уж не знаю как оно в таком случае будет называться) дерева могут и будут замыкаться. С помощью такой структуры вполне можно описать нижеприведеную схему:

---000-----000--|
| |
--|--000--|--000--|--000--|--
| |
|--000-----000--|

По-ходу станет ясно, насколько эта структура подходит.

mab>Боюсь, Ваш вопрос совсем не алгоритмический, а скорее технический.
А вот это спорно.

PS: Думал на ты с вами (как собс-но и со всеми), но Вы упорно пишете Вы (:

Здравствуйте, Al_, Вы писали:

Al_>Теперь ясно почему так роете под меня (%. Давно я с графами дело имел и забыл, что он в первую очередь описывается векторами/отрезками, а не массивами чисел (о чем я подразумевал, это и требовал от Вас).
Какими векторами/отрезками? Граф обычно описывается множеством вершин (например, числа 1..N) и ребер (списками смежности/инцидентности, матрицами смежности/инцидентности).

mab>>Сильно... И какой же у этого объекта планируется интерфейс?
Al_>Что Вы имеете ввиду?

Ну... если есть объект, то значит все таки он должен реализовать какой-то набор методов, иметь какие-то атрибуты/свойства, как-то влючаться в общую иерархию наследования и т.п. Вроде бы именно это имеют в виду, говоря про ООП. В каком смысле этот термин употреблен у тебя, я до сих пор не понимаю.


Al_>Но насчет "чисто последовательной" Вы зря. Ветви "моего" (уж не знаю как оно в таком случае будет называться) дерева могут и будут замыкаться. С помощью такой структуры вполне можно описать нижеприведеную схему:

Al_> ---000-----000--|
Al_> | |
Al_>--|--000--|--000--|--000--|--
Al_> | |
Al_> |--000-----000--|

Совет дня: лучше использовать моноширинный шрифт для таких картинок, а в Aral-е то сложно что-то увидеть.

Ну ради бога, перестань называть этот ужас деревом, тебя никто не поймет, да еще издеваться будут. В дереве нет циклов, просто по определению.

Это граф произвольного произвольного вида, вряд ли его можно назвать как-то подругому.

mab>>Боюсь, Ваш вопрос совсем не алгоритмический, а скорее технический.
Al_>А вот это спорно.

В настоящий момент я не очень понимаю, в чем у тебя проблема. Вроде бы алгоритм изложен достаточно четко. Единственное, что мешает ему быть реализованным -- остуствие формата входных данных. Вот именно его я и называю технической проблемой.

Итак, как и в каком виде данные подаются на вход? Только не надо говорить про ООП и рисовать странные картинки, они сути дела не проясняют.

Al_>PS: Думал на ты с вами (как собс-но и со всеми), но Вы упорно пишете Вы (:
Пофиксено

Здравствуйте, mab, Вы писали:

Al_>>Теперь ясно почему так роете под меня (%. Давно я с графами дело имел и забыл, что он в первую очередь описывается векторами/отрезками, а не массивами чисел (о чем я подразумевал, это и требовал от Вас).
mab>Какими векторами/отрезками? Граф обычно описывается множеством вершин (например, числа 1..N) и ребер (списками смежности/инцидентности, матрицами смежности/инцидентности).
Вообщето я это и имел ввиду изначально. То есть как раз составление матриц, описывающих граф. Ты только больше запутал...

mab>>>Сильно... И какой же у этого объекта планируется интерфейс?
Al_>>Что Вы имеете ввиду?

mab>Ну... если есть объект, то значит все таки он должен реализовать какой-то набор методов, иметь какие-то атрибуты/свойства, как-то влючаться в общую иерархию наследования и т.п.
Наследование [пока] здесь непричем.
mab>Вроде бы именно это имеют в виду, говоря про ООП. В каком смысле этот термин употреблен у тебя, я до сих пор не понимаю.
В первую очередь, я думаю, имеют ввиду инкапсуляцию. И для этого есть своя терминология. Интерфейс — понятие слишком размытое.
К свойствам в первую очередь относятся Собственый импеданс объекта, затем указатели на рядом находящиеся + еще куча всего добавится по мере развития.
К методам — различные расчетные операции, например перебор путей от одного объекта к другому, посредством рекурентного вызова; Если потребуется, то аналогичным способом составить матрицу инциденции; Затем, возможно, пользовательский интерфейс, для редактирования свойств объекта, да мало ли...

Al_>>Но насчет "чисто последовательной" Вы зря. Ветви "моего" (уж не знаю как оно в таком случае будет называться) дерева могут и будут замыкаться. С помощью такой структуры вполне можно описать нижеприведеную схему:

  ---000-----000--|
  |               |
--|--000--|--000--|--000--|--
          |               |
          |--000-----000--|

mab>Совет дня: лучше использовать моноширинный шрифт для таких картинок, а в Aral-е то сложно что-то увидеть.
Уж не знал, что для редактирования и просмотра используются разные шрифты, виноват. /:

mab>Ну ради бога, перестань называть этот ужас деревом, тебя никто не поймет, да еще издеваться будут. В дереве нет циклов, просто по определению.
Почему ужас... очень даже гибкая система, позволяющая организовать различные энергосистемы на любом уровне. (Будь то отдельная ВЛ, будь это система электроснабжения города).

mab>Это граф произвольного произвольного вида, вряд ли его можно назвать как-то подругому.
Вот и прекрасно, на этом и остановимся.

mab>>>Боюсь, Ваш вопрос совсем не алгоритмический, а скорее технический.
Al_>>А вот это спорно.
mab>В настоящий момент я не очень понимаю, в чем у тебя проблема. Вроде бы алгоритм изложен достаточно четко. Единственное, что мешает ему быть реализованным -- остуствие формата входных данных. Вот именно его я и называю технической проблемой.
А думаешь ложить эти исходные данные на такой алгоритм легко?

mab>Итак, как и в каком виде данные подаются на вход? Только не надо говорить про ООП и рисовать странные картинки, они сути дела не проясняют.
Разве тебе картинка ничего не прояснила? Такие вещи, имхо, проще показывать рисунками. Тогда попробую привести исходный класс.

class CObject
{
private:
    CObject *pPrevItem;
    CQueue *pNextItems;
public:
    double Impedans;
    CObject();
    virtual ~CObject();
    void UprosititiFrom(CObject *pItem);
    CObject *GetFirstItem();
    CObject *GetLastItem();
};

Или, может, ты сомневаешься в необходимости использования ООП... /:

Здравствуйте, Al_, Вы писали:

Al_>Вообщето я это и имел ввиду изначально. То есть как раз составление матриц, описывающих граф. Ты только больше запутал...

Al_>Или, может, ты сомневаешься в необходимости использования ООП... /:
Звучит прямо как "ты за советскую власть?
Все хорошо в меру, тем более что ООП и чистая алгоритмистика иногда вообще не сочетаемые вещи.
По крайней мере я с трудом представляю, как можно пользоваться предложенным интерфейсом.

Al_>

Al_>class CObject
Al_>{
Al_>private:
Al_>    CObject *pPrevItem;
Al_>    CQueue *pNextItems;
Al_>public:
Al_>    double Impedans;
Al_>    CObject();
Al_>    virtual ~CObject();
Al_>    void UprosititiFrom(CObject *pItem);
Al_>    CObject *GetFirstItem();
Al_>    CObject *GetLastItem();
Al_>};
Al_>

Что такое UprosititiFrom(), GetLastItem(), GetFirstItem()?


Al_>К свойствам в первую очередь относятся Собственый импеданс объекта, затем указатели на рядом находящиеся + еще куча
всего добавится по мере развития.
Что такое "рядом находящиеся"? И что означает "еще куча добавится"? Решать-то задачу нужно сейчас а не потом, вот я и спрашиваю, какой будет интерфейс (уж извини за постоянное употребление этого слова ) через который можно будет о схеме узнать ее структуру? Или предполагается логику вычислений распихать по методам самого класса? Это IHMO тупиковый подход, вот здесь про ООП стоит окончательно и забыть.

Al_>К методам — различные расчетные операции, например перебор путей от одного объекта к другому, посредством рекурентного вызова;
Зачем это нужно?

Al_>Если потребуется, то аналогичным способом составить матрицу инциденции; Затем, возможно, пользовательский интерфейс, для редактирования свойств объекта, да мало ли...
Все это к поставленной задаче прямого отношения не имеет.

Al_>Почему ужас... очень даже гибкая система, позволяющая организовать различные энергосистемы на любом уровне. (Будь то отдельная ВЛ, будь это система электроснабжения города).
Ну прекрасно, может она и дико гибкая, но как можно в ней что-то вычислить я не понимаю.

Al_>А думаешь ложить эти исходные данные на такой алгоритм легко?
Насчет "ложить" не знаю
Вообще же здесь есть ошибка проектирования (с точки зрения ООП): имеем класс, представляющий элемент, а сам контейнер никакому классу не соответствует. На мой взгляд, именно контейнер должен решать вопрос о построении матрицы смежности графа по собственному содержимому.

Здравствуйте, mab, Вы писали:

Al_>>Или, может, ты сомневаешься в необходимости использования ООП... /:
mab>Звучит прямо как "ты за советскую власть?
(: Почти так и есть. Мне интересен этот подход. Думаю не придется отказываться от него.

mab>Все хорошо в меру, тем более что ООП и чистая алгоритмистика иногда вообще не сочетаемые вещи.
mab>По крайней мере я с трудом представляю, как можно пользоваться предложенным интерфейсом.
Можно, но со своей спецификой. Вызовы практически всех методов рекурентные, это здорово увеличивает производительость.

Al_>>

Al_>>class CObject
Al_>>{
Al_>>private:
Al_>>    CObject *pPrevItem;
Al_>>    CQueue *pNextItems;
Al_>>public:
Al_>>    double Impedans;
Al_>>    CObject();
Al_>>    virtual ~CObject();
Al_>>    void UprosititiFrom(CObject *pItem);
Al_>>    CObject *GetFirstItem();
Al_>>    CObject *GetLastItem();
Al_>>};
Al_>>

mab>Что такое UprosititiFrom(), GetLastItem(), GetFirstItem()?
Первая, например, упрощает схему, сокращая количество объектов.
GetFirstItem() — возвращает указатель на самый первый элемент;
GetLastItem() — этот пока ничего, но будет использоваться для перебора путей, ести таковой потребуется.

Al_>>К свойствам в первую очередь относятся Собственый импеданс объекта, затем указатели на рядом находящиеся + еще куча всего добавится по мере развития.
mab>Что такое "рядом находящиеся"?
...элементы. см. класс.

mab>И что означает "еще куча добавится"? Решать-то задачу нужно сейчас а не потом,
Никогда не занимаюсь распределением методов/свойств (кто за что отвечает) до написания кода. Имхо, пустая трата времени. Лучше написать и наглядно оценить, затем что надо переделать. Может еще блок-схему посоветуешь написать перед началом? /:

mab> вот я и спрашиваю, какой будет интерфейс (уж извини за постоянное употребление этого слова ) через который можно будет о схеме узнать ее структуру? Или предполагается логику вычислений распихать по методам самого класса?
Какую-то часть обязательно распихаю, возможно всю.

mab> Это IHMO тупиковый подход, вот здесь про ООП стоит окончательно и забыть.
Посмотрим. Как дойду до дела. Возможно что-то и вынесу за пределы ООП, в чем проблема-то?! тут главное эхотаг продумать (:

Al_>>К методам — различные расчетные операции, например перебор путей от одного объекта к другому, посредством рекурентного вызова;
mab>Зачем это нужно?
Что? Перебор путей? Да мало-ли что может потребоваться...

Al_>>Если потребуется, то аналогичным способом составить матрицу инциденции; Затем, возможно, пользовательский интерфейс, для редактирования свойств объекта, да мало ли...
mab>Все это к поставленной задаче прямого отношения не имеет.
Расшираемость — вот главное преимущество. А без неё мне и нафиг не нужно (%

Al_>>Почему ужас... очень даже гибкая система, позволяющая организовать различные энергосистемы на любом уровне. (Будь то отдельная ВЛ, будь это система электроснабжения города).
mab>Ну прекрасно, может она и дико гибкая, но как можно в ней что-то вычислить я не понимаю.
Можно — можно...

Al_>>А думаешь ложить эти исходные данные на такой алгоритм легко?
mab>Насчет "ложить" не знаю
(: Ну, блин, юморист. Вполне нормальный словооборот...
mab>Вообще же здесь есть ошибка проектирования (с точки зрения ООП): имеем класс, представляющий элемент, а сам контейнер никакому классу не соответствует. На мой взгляд, именно контейнер должен решать вопрос о построении матрицы смежности графа по собственному содержимому.
При желании можно обойтись и без него. Да и создать его всегда можно.

Здравствуйте, Al_!

Я давно так не смеялся, ей-богу!

Здравствуйте, Al_, Вы писали:

Давай я попробую раз и навсегда прояснить, почему предоложенный "подход" мне кажется довольно абсурдным.

mab>>Звучит прямо как "ты за советскую власть?
Al_>(: Почти так и есть. Мне интересен этот подход. Думаю не придется отказываться от него.
Подход, конечно, вещь хорошая, но при неправильном (а точнее, уж прости, неумелом) применении от него страдают все, и в первую очередь -- тот, кто применяет.

Al_>Можно, но со своей спецификой. Вызовы практически всех методов рекурентные, это здорово увеличивает производительость.
Во-первых, скорее уж рекурсивные. Во-вторых, увеличивает по сравнению с чем? Может напомнить пример про вычисление чисел Фибоначчи по реккуррентному соотношению?

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

В-четверых: зачем в рамках решаемой задачи это нужно

Al_>>>

Al_>>>class CObject
Al_>>>{
Al_>>>private:
Al_>>>    CObject *pPrevItem;
Al_>>>    CQueue *pNextItems;
Al_>>>public:
Al_>>>    double Impedans;
Al_>>>    CObject();
Al_>>>    virtual ~CObject();
Al_>>>    void UprosititiFrom(CObject *pItem);
Al_>>>    CObject *GetFirstItem();
Al_>>>    CObject *GetLastItem();
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 объяснено уже все: по схеме строишь систему ЛУ, а потом ее решаешь, например Гауссом. Еще советую обратить внимание на те ссылки, которые тебе дали -- весьма полезно.