Есть ли эффективный способ динамического изменения compress_matrix в boost? - PullRequest
10 голосов
/ 15 ноября 2010

Я использую ublas :: Compressed Matrix для работы с UMFPACK, разреженным линейным решателем.Поскольку я занимаюсь моделированием, то каждый раз линейная система строится немного по-другому, что может включать увеличение / уменьшение матрицы коэффициентов и некоторые редкие умножения матриц.Масштаб линейной системы составляет около 25 тыс.

Даже при наличии обязательного патча для надстройки для работы с UMFPACK, мне все еще нужно время от времени менять матрицу, иногда даже вычисляя количествонулевые значения будут занимать много времени (в идеале, я должен указывать количество ненулевых значений при инициализации матрицы).Кроме того, я использую ublas :: range для динамического добавления столбцов / строк.

Итак, мой вопрос: есть ли эффективный способ сделать это?Сейчас это слишком медленно для меня.Транспонирование матрицы с размером, например 15 КБ, стоит почти 6 с, а добавление около 12 КБ строк - это быстро (потому что я думаю, что это матрица с основными строками), но добавление такого же количества столбцов в матрицу может стоить до 20 с (я думаю, для того жепричина, как указано выше, так что даже я использовал матрицу столбцов-мажоров, и общее время, необходимое для этого, было бы одинаковым).

Какая-то отчаянная ситуация здесь.Любые предложения приветствуются.

Приветствия.

Ответы [ 4 ]

1 голос
/ 18 декабря 2010

Я не знаком с вашими пакетами, но почему вы (в идеале) должны указывать количество ненулевых элементов в вашей матрице? Вы не можете переопределить, а затем уменьшить в размере?

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

Последнее кажется вероятным. Я попытался бы свернуть свой собственный код «вставить столбец», который принимает текущую разреженную матрицу, вычисляет, сколько еще записей, выделяет больший блок и копирует последовательно, вставляя новые столбцы по мере продвижения. Это линейно и должно быть по существу мгновенным. Я не знаю, достаточно ли этого для решения всей проблемы, но это должно быть началом.

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

0 голосов
/ 21 марта 2012

Вы пробовали Eigen для такого рода проблем? Недавно они завершили поддержку разреженных матриц.

0 голосов
/ 21 мая 2011

Вместо того чтобы строить A путем объединения нескольких различных наборов значений, вы рассматривали вопрос о том, чтобы хранить их в отдельных матрицах и использовать существующие подпрограммы решателя для создания собственного общего решателя? По сути, вы применили бы соответствующую декомпозицию (LU, QR и т. Д.) К одной матрице компонентов, запустили соответствующее обновление / преобразование для последующих компонентов и повторили для каждой последующей матрицы. Затем вы будете использовать факторизованные матрицы компонентов для вычисления вашего решения. Неясно, будет ли библиотека, с которой вы работали, поддерживать это напрямую, или вам придется самостоятельно писать некоторые / все числовые подпрограммы.

0 голосов
/ 10 декабря 2010

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

А вы используете флаг -DNDEBUG для uBlas, верно?

Я до сих пор не уверен, в чем проблема ...

Лучший Умут

...