Итак, задача: имеется неориентированный граф, в котором присутствует некое количество источников и стоков (A и B соотв.), каждый источник может поставить a_i элементов и каждый сток принять b_i элементов. Требуется рассчитать сколько элементов и по каким путям (веса ребёр одинаковы) необходимо пустить, чтобы заполнить стоки (частично, полностью или даже переполнить — не имеет значения). Естественно, оптимальности никто не требует, достаточно хорошего приближения.

Собственно, коллеги, намекните с какими численными методами нужно познакомиться для решения данной задачи (готовое решение, разумеется, я от вас и не требовал — сам хочу разобраться). Тут, на мой взгляд, что-то довольно близкое к транспортной задаче, но на больно специфической нише (графы, однако). А все алгоритмы макс. потока, что я знаю, предполагают наличие единственной пары источник-сток.

Вот всё никак не могу понять, зачем вообще нужны эти выкидыши SGML?
Куда ни плюнь: сайты на HTML, всякие RDF, RSS, SVG, XMPP (он же Jabber), огромное количество конфигов программ на XML, в C# вовсю вкручивают его нативную поддержку (а уж комментарии на XML это просто нечто), даже новый RT Fact с главной страницы и тот юзает (кто бы мог подумать) XML3D. Вопрос: почему?
Он же крайне избыточен, неоднозначен, сложно парсится как программами, так и (ещё более сложнее) людьми, а его мифическая гибкость никому не сдалась и в одном проценте софта, его использующего.
Есть же намного более удобные YAML, JSON, sexp`ы, наконец. FFUUU~

Итак, здесь мы можем наблюдать свежеустановленную генту ~amd64 на no-multilib профиле. Стоит она стоит на сжатом reiser4 разделе, смонтированном в read-only, вынесенный с корня /var так же на reiser4+lzo1; полёт нормальный.

Emacs для всего, что связано с информацией в текстовом виде, а так же для imaxima и jabber; унылый dired чересчур уныл, поэтому использую mc. Вот сейчас ковыряю потихоньку мой дипломный проект для технаря.

В качестве терминала используется urxvt, в качестве музыкального плеера, как уже заметили, mpd+ncmpcpp, картинки смотрю в feh, pdfки и djvu в evince, видео в голом mplayer. Да, если интересно, то иконка в трее от ibus (нужен для корректной работы переключалки emacs и для возможности вбивать в гугле по-японски).

Абсолютно на всё натянута цветовая схема zenburn (даже stardict пропатчил), шрифт Consolas-15, cairo, libXft и freetype с патчами cleartype. Монитор у меня 21.5", а, учитывая, что за экраном провожу довольно много времени, данное решение является для меня идеальным (не темно и шрифты не велики).

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

Конфиги emacs, ncmpcpp, awesome и mc (включая .gtkrc-2.0 и .Xdefaults) можно скачать отсюда: http://ifolder.ru/16423757