По какой причине LAPACK использует

9

QR-код LAPACK хранит Q в качестве отражателей для домохозяев. Он масштабирует вектор отражения с , поэтому первый элемент результата становится , поэтому его не нужно сохранять. И он хранит отдельный вектор , который содержит необходимые масштабные коэффициенты. Таким образом, матрица отражателя выглядит так: $v$ $1/v_1$ $1$ $\tau$

ЧАС знак равно я - τ v v^{T},

$H=I-\tau v v^T,$

где не нормируется. В то время как в учебниках матрица отражателей $v$

ЧАС знак равно я - 2 v v^{T},

$H = I-2vv^T,$

где нормализуется. $v$

Почему LAPACK масштабирует с вместо его нормализации? $v$ $1/v_1$

Необходимое хранилище остается тем же (вместо , должно быть сохранено), и после этого применение может быть выполнено быстрее, так как нет необходимости умножать на (умножение на в версии учебника можно оптимизировать, если вместо простой нормализации масштабируется как ). $\tau$ $v_1$ $H$ $\tau$ $2$ $v$ $\sqrt 2/\|v\|$

(Причина моего вопроса в том, что я пишу процедуру QR и SVD, и я хотел бы знать причину этого решения, нужно ли мне следовать этому или нет)

linear-algebra matrix lapack

— Геза
источник

7

Это заблокированный вариант Householder-QR, который управляет этим дизайном. Если вы посмотрите в книге Голуба и Ван Лоанна (гл. 5.2 или около того), они говорят о том, как k-итерации алгоритма могут быть заблокированы вместе путем накопления отдельных отражателей в отражатель ранга k вида , где и и являются "тощими" матрицами с размером . Этот алгоритм делает больше работы, но быстрее на практике, потому что он богат вызовами gemm (). К сожалению, это расточительно при хранении из-за необходимости представлять и независимо друг от друга. $\mathbf I + \mathbf W \mathbf Y^{\mathrm T}$ $\mathbf W$ $\mathbf Y$ $n \times k$ $\mathbf W$ $\mathbf Y$

В более поздней статье (цитируется ниже) Ван Лоан описывает более эффективную «симметризованную» структуру данных - блочный отражатель в виде . Здесь по-прежнему , но требование создания флопа / памяти для формирования было устранено введением , небольшой верхней треугольной матрицы. Хотя необходимость умножения на вносит небольшой объем дополнительной работы, обычно это чистый выигрыш, потому что . $\mathbf I + \mathbf Y \mathbf T \mathbf Y^{\mathrm T}$ $\mathbf Y$ $n \times k$ $\mathbf W$ $\mathbf T$ $k \times k$ $\mathbf T$ $k << n$

В LAPACK неблокируемый алгоритм на самом деле является просто ограничивающим случаем блочного алгоритма, вплоть до выбора символов (что приводит нас к , небольшой версии треугольник). $k \rightarrow 1$ $\tau$ $1\times1$ $\mathbf T$

Образец цитирования: Шрайбер, Роберт и Чарльз Ван Лоан. «Эффективное для хранения WY представление для продуктов преобразований Домохозяев». Журнал СИАМ по научным и статистическим вычислениям 10.1 (1989): 53-57.

— rchilton1980
источник

Спасибо за ответ! Я не вижу, что находится всего в -sized . В цитируемой статье в Алгоритме 5 равно , а равно -2. Таким образом, он становится версией учебника, а не версией LAPACK. Я что-то пропустил?

τ

$\tau$

1 \times 1

$1 \times 1$

T

$\mathbf T$

Y

$\mathbf Y$

v

$v$

T

$\mathbf T$

— 19

2

Вам не нужно хранить , вы можете пересчитать его из оставшейся части вектора. (Вы можете пересчитать из других записей также в нормализованной версии, но это явно нестабильное вычисление из-за этих вычитаний.) $\tau$ $v_1$

На самом деле, вы можете повторно использовать нижнюю треугольную часть для хранения , так что факторизация вычисляется полностью на месте. Лапак заботится об этих версиях алгоритмов на месте. $R$ $v_2,...v_n$

— Федерико Полони
источник

1

Мое предложение основано на документации для Intel MKL https://software.intel.com/en-us/mkl-developer-reference-c-geqrf . Это выглядит как значения на и выше диагонали выходного хранилища R, поэтому для Q остается только нижний треугольник. Кажется естественным использовать дополнительное хранилище для коэффициентов масштабирования.

— VorKir
источник