Speeding Up Matrix Inversion











up vote
2
down vote

favorite












I need to run this code thousands of time, sequentially:



def update_posterior(y, x, prior_mu, prior_V, prior_a, prior_b):

# Building blocks used to keep following calculation cleaner
prior_cov_inverse = np.linalg.inv(prior_V)
x_transpose = x.transpose()
n = len(y)
residuals = y - np.dot(x, prior_mu.transpose())

# Calculation of posterior parameters
V_posterior = np.linalg.inv((prior_cov_inverse + x_transpose * x))
mu_posterior = (V_posterior * (prior_cov_inverse * prior_mu.transpose() + x_transpose * y)).transpose()
a_posterior = prior_a + n/2
b_posterior = np.asscalar(prior_b + (residuals.transpose() * np.linalg.inv((np.identity(n) + x * prior_V * x_transpose)) * residuals)/2)

return mu_posterior, V_posterior, a_posterior, b_posterior


The way it works is that the output of the function is fed back into it, with mu_posterior becoming prior_mu, V_posterior becoming prior_V, a_posterior becoming prior_a, and b_posterior becoming prior_b for the next call. The y and x are different in each call.



This function is horrendously slow--it takes me about 8 seconds to run. This is because of the scale. I have ~5000 parameters, so prior_mu is (1, 5000), prior_V is (5000,5000) and symmetric positive-definite, and prior_a, and prior_b are scalars. y is a scalar, and x is (1, 5000).



Here is the time breakdown by line:



3.75s: prior_cov_inverse = np.linalg.inv(prior_V)
3.86s: V_posterior = np.linalg.inv((prior_cov_inverse + x_transpose * x))
0.13s: b_posterior = np.asscalar(prior_b + (residuals.transpose() * np.linalg.inv((np.identity(n) + x * prior_V * x_transpose)) * residuals)/2)


Any ideas how I can speed it up? I tried to use a Cholesky decomposition but it's even slower?! My guess is there is a more efficient way to implement Cholesky decomposition in Python.



prior_cov_inverse2 = np.linalg.inv(np.linalg.cholesky(prior_V))
prior_cov_inverse2 = np.dot(prior_cov_inverse2.transpose(), prior_cov_inverse2)


EDIT: Here are some sample data to illustrate the issue....



import numpy as np

prior_mu = np.asmatrix(np.full((1, 5040), 5))
prior_V = np.diagflat(np.asmatrix(np.full((1, 5040), 30))) #usually not diagonal, but always symmetric positive definitive
a = 2
b = 2
y = np.asmatrix([10])
x = np.asmatrix(np.concatenate(([1], np.zeros(5039))))

print(update_posterior(y, x, prior_mu, prior_V, a, b))


EDIT II:



I have been able to get this down from ~8s/run to ~1.4s/run by removing matrix inversions in favor of solves and also using the Sherman Morrison formula. Here is my current code. If anyone has any ideas on how to speed it up further, please share! :)



def update_posterior(y, x, prior_mu, prior_V, prior_a, prior_b, I):

# Building blocks used to keep following calculation cleaner
x_transpose = x.transpose()
n = len(y)
residuals = y - np.dot(x, prior_mu.transpose())

# Calculation of posterior parameters
# Below is equivalent to np.linalg.inv(prior_V_inverse + np.dot(x_transpose, x)) but significantly faster
V_posterior = prior_V - np.true_divide(np.linalg.multi_dot((prior_V, x_transpose, x, prior_V)), 1 + np.matmul(np.matmul(x, prior_V), x_transpose))

# Below is equivalent to mu_posterior = np.dot(V_posterior, (np.matmul(prior_V_inverse, prior_mu.transpose()) + np.matmul(x_transpose, y))).transpose() but significantly faster
mu_posterior = np.dot(V_posterior, np.linalg.solve(prior_V, prior_mu.transpose()) + np.matmul(x_transpose, y)).transpose()
a_posterior = prior_a + n/2
b_posterior = np.asscalar(prior_b + (np.matmul(np.matmul(residuals.transpose(), np.linalg.inv((np.identity(n) + np.matmul(np.matmul(x, prior_V), x_transpose)))), residuals))/2)

return mu_posterior, V_posterior, a_posterior, b_posterior









share|improve this question




















  • 3




    Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
    – Paul Brodersen
    Nov 19 at 9:38






  • 1




    Sure that y is a scalar? If so, n = len(y) is slightly misleading. I guess it might be helpful to post sample data for y, x, prior_mu, prior_V, prior_a and prior_b. By the way, you could take a look at Numba.
    – joni
    Nov 19 at 10:41










  • @PaulBrodersen I am not 100% sure I need to invert them, but I am not sure how to restructure this so I do not have to invert them. My current implementation is the "textbook equation" version. y does not have to be scalar, but in practice I am putting in only one x,y pair into the model at a time.
    – purpleostrich
    Nov 19 at 19:14












  • @joni I added some sample data, thank you!
    – purpleostrich
    Nov 19 at 19:36















up vote
2
down vote

favorite












I need to run this code thousands of time, sequentially:



def update_posterior(y, x, prior_mu, prior_V, prior_a, prior_b):

# Building blocks used to keep following calculation cleaner
prior_cov_inverse = np.linalg.inv(prior_V)
x_transpose = x.transpose()
n = len(y)
residuals = y - np.dot(x, prior_mu.transpose())

# Calculation of posterior parameters
V_posterior = np.linalg.inv((prior_cov_inverse + x_transpose * x))
mu_posterior = (V_posterior * (prior_cov_inverse * prior_mu.transpose() + x_transpose * y)).transpose()
a_posterior = prior_a + n/2
b_posterior = np.asscalar(prior_b + (residuals.transpose() * np.linalg.inv((np.identity(n) + x * prior_V * x_transpose)) * residuals)/2)

return mu_posterior, V_posterior, a_posterior, b_posterior


The way it works is that the output of the function is fed back into it, with mu_posterior becoming prior_mu, V_posterior becoming prior_V, a_posterior becoming prior_a, and b_posterior becoming prior_b for the next call. The y and x are different in each call.



This function is horrendously slow--it takes me about 8 seconds to run. This is because of the scale. I have ~5000 parameters, so prior_mu is (1, 5000), prior_V is (5000,5000) and symmetric positive-definite, and prior_a, and prior_b are scalars. y is a scalar, and x is (1, 5000).



Here is the time breakdown by line:



3.75s: prior_cov_inverse = np.linalg.inv(prior_V)
3.86s: V_posterior = np.linalg.inv((prior_cov_inverse + x_transpose * x))
0.13s: b_posterior = np.asscalar(prior_b + (residuals.transpose() * np.linalg.inv((np.identity(n) + x * prior_V * x_transpose)) * residuals)/2)


Any ideas how I can speed it up? I tried to use a Cholesky decomposition but it's even slower?! My guess is there is a more efficient way to implement Cholesky decomposition in Python.



prior_cov_inverse2 = np.linalg.inv(np.linalg.cholesky(prior_V))
prior_cov_inverse2 = np.dot(prior_cov_inverse2.transpose(), prior_cov_inverse2)


EDIT: Here are some sample data to illustrate the issue....



import numpy as np

prior_mu = np.asmatrix(np.full((1, 5040), 5))
prior_V = np.diagflat(np.asmatrix(np.full((1, 5040), 30))) #usually not diagonal, but always symmetric positive definitive
a = 2
b = 2
y = np.asmatrix([10])
x = np.asmatrix(np.concatenate(([1], np.zeros(5039))))

print(update_posterior(y, x, prior_mu, prior_V, a, b))


EDIT II:



I have been able to get this down from ~8s/run to ~1.4s/run by removing matrix inversions in favor of solves and also using the Sherman Morrison formula. Here is my current code. If anyone has any ideas on how to speed it up further, please share! :)



def update_posterior(y, x, prior_mu, prior_V, prior_a, prior_b, I):

# Building blocks used to keep following calculation cleaner
x_transpose = x.transpose()
n = len(y)
residuals = y - np.dot(x, prior_mu.transpose())

# Calculation of posterior parameters
# Below is equivalent to np.linalg.inv(prior_V_inverse + np.dot(x_transpose, x)) but significantly faster
V_posterior = prior_V - np.true_divide(np.linalg.multi_dot((prior_V, x_transpose, x, prior_V)), 1 + np.matmul(np.matmul(x, prior_V), x_transpose))

# Below is equivalent to mu_posterior = np.dot(V_posterior, (np.matmul(prior_V_inverse, prior_mu.transpose()) + np.matmul(x_transpose, y))).transpose() but significantly faster
mu_posterior = np.dot(V_posterior, np.linalg.solve(prior_V, prior_mu.transpose()) + np.matmul(x_transpose, y)).transpose()
a_posterior = prior_a + n/2
b_posterior = np.asscalar(prior_b + (np.matmul(np.matmul(residuals.transpose(), np.linalg.inv((np.identity(n) + np.matmul(np.matmul(x, prior_V), x_transpose)))), residuals))/2)

return mu_posterior, V_posterior, a_posterior, b_posterior









share|improve this question




















  • 3




    Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
    – Paul Brodersen
    Nov 19 at 9:38






  • 1




    Sure that y is a scalar? If so, n = len(y) is slightly misleading. I guess it might be helpful to post sample data for y, x, prior_mu, prior_V, prior_a and prior_b. By the way, you could take a look at Numba.
    – joni
    Nov 19 at 10:41










  • @PaulBrodersen I am not 100% sure I need to invert them, but I am not sure how to restructure this so I do not have to invert them. My current implementation is the "textbook equation" version. y does not have to be scalar, but in practice I am putting in only one x,y pair into the model at a time.
    – purpleostrich
    Nov 19 at 19:14












  • @joni I added some sample data, thank you!
    – purpleostrich
    Nov 19 at 19:36













up vote
2
down vote

favorite









up vote
2
down vote

favorite











I need to run this code thousands of time, sequentially:



def update_posterior(y, x, prior_mu, prior_V, prior_a, prior_b):

# Building blocks used to keep following calculation cleaner
prior_cov_inverse = np.linalg.inv(prior_V)
x_transpose = x.transpose()
n = len(y)
residuals = y - np.dot(x, prior_mu.transpose())

# Calculation of posterior parameters
V_posterior = np.linalg.inv((prior_cov_inverse + x_transpose * x))
mu_posterior = (V_posterior * (prior_cov_inverse * prior_mu.transpose() + x_transpose * y)).transpose()
a_posterior = prior_a + n/2
b_posterior = np.asscalar(prior_b + (residuals.transpose() * np.linalg.inv((np.identity(n) + x * prior_V * x_transpose)) * residuals)/2)

return mu_posterior, V_posterior, a_posterior, b_posterior


The way it works is that the output of the function is fed back into it, with mu_posterior becoming prior_mu, V_posterior becoming prior_V, a_posterior becoming prior_a, and b_posterior becoming prior_b for the next call. The y and x are different in each call.



This function is horrendously slow--it takes me about 8 seconds to run. This is because of the scale. I have ~5000 parameters, so prior_mu is (1, 5000), prior_V is (5000,5000) and symmetric positive-definite, and prior_a, and prior_b are scalars. y is a scalar, and x is (1, 5000).



Here is the time breakdown by line:



3.75s: prior_cov_inverse = np.linalg.inv(prior_V)
3.86s: V_posterior = np.linalg.inv((prior_cov_inverse + x_transpose * x))
0.13s: b_posterior = np.asscalar(prior_b + (residuals.transpose() * np.linalg.inv((np.identity(n) + x * prior_V * x_transpose)) * residuals)/2)


Any ideas how I can speed it up? I tried to use a Cholesky decomposition but it's even slower?! My guess is there is a more efficient way to implement Cholesky decomposition in Python.



prior_cov_inverse2 = np.linalg.inv(np.linalg.cholesky(prior_V))
prior_cov_inverse2 = np.dot(prior_cov_inverse2.transpose(), prior_cov_inverse2)


EDIT: Here are some sample data to illustrate the issue....



import numpy as np

prior_mu = np.asmatrix(np.full((1, 5040), 5))
prior_V = np.diagflat(np.asmatrix(np.full((1, 5040), 30))) #usually not diagonal, but always symmetric positive definitive
a = 2
b = 2
y = np.asmatrix([10])
x = np.asmatrix(np.concatenate(([1], np.zeros(5039))))

print(update_posterior(y, x, prior_mu, prior_V, a, b))


EDIT II:



I have been able to get this down from ~8s/run to ~1.4s/run by removing matrix inversions in favor of solves and also using the Sherman Morrison formula. Here is my current code. If anyone has any ideas on how to speed it up further, please share! :)



def update_posterior(y, x, prior_mu, prior_V, prior_a, prior_b, I):

# Building blocks used to keep following calculation cleaner
x_transpose = x.transpose()
n = len(y)
residuals = y - np.dot(x, prior_mu.transpose())

# Calculation of posterior parameters
# Below is equivalent to np.linalg.inv(prior_V_inverse + np.dot(x_transpose, x)) but significantly faster
V_posterior = prior_V - np.true_divide(np.linalg.multi_dot((prior_V, x_transpose, x, prior_V)), 1 + np.matmul(np.matmul(x, prior_V), x_transpose))

# Below is equivalent to mu_posterior = np.dot(V_posterior, (np.matmul(prior_V_inverse, prior_mu.transpose()) + np.matmul(x_transpose, y))).transpose() but significantly faster
mu_posterior = np.dot(V_posterior, np.linalg.solve(prior_V, prior_mu.transpose()) + np.matmul(x_transpose, y)).transpose()
a_posterior = prior_a + n/2
b_posterior = np.asscalar(prior_b + (np.matmul(np.matmul(residuals.transpose(), np.linalg.inv((np.identity(n) + np.matmul(np.matmul(x, prior_V), x_transpose)))), residuals))/2)

return mu_posterior, V_posterior, a_posterior, b_posterior









share|improve this question















I need to run this code thousands of time, sequentially:



def update_posterior(y, x, prior_mu, prior_V, prior_a, prior_b):

# Building blocks used to keep following calculation cleaner
prior_cov_inverse = np.linalg.inv(prior_V)
x_transpose = x.transpose()
n = len(y)
residuals = y - np.dot(x, prior_mu.transpose())

# Calculation of posterior parameters
V_posterior = np.linalg.inv((prior_cov_inverse + x_transpose * x))
mu_posterior = (V_posterior * (prior_cov_inverse * prior_mu.transpose() + x_transpose * y)).transpose()
a_posterior = prior_a + n/2
b_posterior = np.asscalar(prior_b + (residuals.transpose() * np.linalg.inv((np.identity(n) + x * prior_V * x_transpose)) * residuals)/2)

return mu_posterior, V_posterior, a_posterior, b_posterior


The way it works is that the output of the function is fed back into it, with mu_posterior becoming prior_mu, V_posterior becoming prior_V, a_posterior becoming prior_a, and b_posterior becoming prior_b for the next call. The y and x are different in each call.



This function is horrendously slow--it takes me about 8 seconds to run. This is because of the scale. I have ~5000 parameters, so prior_mu is (1, 5000), prior_V is (5000,5000) and symmetric positive-definite, and prior_a, and prior_b are scalars. y is a scalar, and x is (1, 5000).



Here is the time breakdown by line:



3.75s: prior_cov_inverse = np.linalg.inv(prior_V)
3.86s: V_posterior = np.linalg.inv((prior_cov_inverse + x_transpose * x))
0.13s: b_posterior = np.asscalar(prior_b + (residuals.transpose() * np.linalg.inv((np.identity(n) + x * prior_V * x_transpose)) * residuals)/2)


Any ideas how I can speed it up? I tried to use a Cholesky decomposition but it's even slower?! My guess is there is a more efficient way to implement Cholesky decomposition in Python.



prior_cov_inverse2 = np.linalg.inv(np.linalg.cholesky(prior_V))
prior_cov_inverse2 = np.dot(prior_cov_inverse2.transpose(), prior_cov_inverse2)


EDIT: Here are some sample data to illustrate the issue....



import numpy as np

prior_mu = np.asmatrix(np.full((1, 5040), 5))
prior_V = np.diagflat(np.asmatrix(np.full((1, 5040), 30))) #usually not diagonal, but always symmetric positive definitive
a = 2
b = 2
y = np.asmatrix([10])
x = np.asmatrix(np.concatenate(([1], np.zeros(5039))))

print(update_posterior(y, x, prior_mu, prior_V, a, b))


EDIT II:



I have been able to get this down from ~8s/run to ~1.4s/run by removing matrix inversions in favor of solves and also using the Sherman Morrison formula. Here is my current code. If anyone has any ideas on how to speed it up further, please share! :)



def update_posterior(y, x, prior_mu, prior_V, prior_a, prior_b, I):

# Building blocks used to keep following calculation cleaner
x_transpose = x.transpose()
n = len(y)
residuals = y - np.dot(x, prior_mu.transpose())

# Calculation of posterior parameters
# Below is equivalent to np.linalg.inv(prior_V_inverse + np.dot(x_transpose, x)) but significantly faster
V_posterior = prior_V - np.true_divide(np.linalg.multi_dot((prior_V, x_transpose, x, prior_V)), 1 + np.matmul(np.matmul(x, prior_V), x_transpose))

# Below is equivalent to mu_posterior = np.dot(V_posterior, (np.matmul(prior_V_inverse, prior_mu.transpose()) + np.matmul(x_transpose, y))).transpose() but significantly faster
mu_posterior = np.dot(V_posterior, np.linalg.solve(prior_V, prior_mu.transpose()) + np.matmul(x_transpose, y)).transpose()
a_posterior = prior_a + n/2
b_posterior = np.asscalar(prior_b + (np.matmul(np.matmul(residuals.transpose(), np.linalg.inv((np.identity(n) + np.matmul(np.matmul(x, prior_V), x_transpose)))), residuals))/2)

return mu_posterior, V_posterior, a_posterior, b_posterior






numpy optimization scipy statistics






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 20 at 6:19

























asked Nov 19 at 5:33









purpleostrich

164




164








  • 3




    Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
    – Paul Brodersen
    Nov 19 at 9:38






  • 1




    Sure that y is a scalar? If so, n = len(y) is slightly misleading. I guess it might be helpful to post sample data for y, x, prior_mu, prior_V, prior_a and prior_b. By the way, you could take a look at Numba.
    – joni
    Nov 19 at 10:41










  • @PaulBrodersen I am not 100% sure I need to invert them, but I am not sure how to restructure this so I do not have to invert them. My current implementation is the "textbook equation" version. y does not have to be scalar, but in practice I am putting in only one x,y pair into the model at a time.
    – purpleostrich
    Nov 19 at 19:14












  • @joni I added some sample data, thank you!
    – purpleostrich
    Nov 19 at 19:36














  • 3




    Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
    – Paul Brodersen
    Nov 19 at 9:38






  • 1




    Sure that y is a scalar? If so, n = len(y) is slightly misleading. I guess it might be helpful to post sample data for y, x, prior_mu, prior_V, prior_a and prior_b. By the way, you could take a look at Numba.
    – joni
    Nov 19 at 10:41










  • @PaulBrodersen I am not 100% sure I need to invert them, but I am not sure how to restructure this so I do not have to invert them. My current implementation is the "textbook equation" version. y does not have to be scalar, but in practice I am putting in only one x,y pair into the model at a time.
    – purpleostrich
    Nov 19 at 19:14












  • @joni I added some sample data, thank you!
    – purpleostrich
    Nov 19 at 19:36








3




3




Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
– Paul Brodersen
Nov 19 at 9:38




Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
– Paul Brodersen
Nov 19 at 9:38




1




1




Sure that y is a scalar? If so, n = len(y) is slightly misleading. I guess it might be helpful to post sample data for y, x, prior_mu, prior_V, prior_a and prior_b. By the way, you could take a look at Numba.
– joni
Nov 19 at 10:41




Sure that y is a scalar? If so, n = len(y) is slightly misleading. I guess it might be helpful to post sample data for y, x, prior_mu, prior_V, prior_a and prior_b. By the way, you could take a look at Numba.
– joni
Nov 19 at 10:41












@PaulBrodersen I am not 100% sure I need to invert them, but I am not sure how to restructure this so I do not have to invert them. My current implementation is the "textbook equation" version. y does not have to be scalar, but in practice I am putting in only one x,y pair into the model at a time.
– purpleostrich
Nov 19 at 19:14






@PaulBrodersen I am not 100% sure I need to invert them, but I am not sure how to restructure this so I do not have to invert them. My current implementation is the "textbook equation" version. y does not have to be scalar, but in practice I am putting in only one x,y pair into the model at a time.
– purpleostrich
Nov 19 at 19:14














@joni I added some sample data, thank you!
– purpleostrich
Nov 19 at 19:36




@joni I added some sample data, thank you!
– purpleostrich
Nov 19 at 19:36












1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










Stability-wise, it's almost always better to write solve(A, unit_matrix) instead of inv(A). That won't help with performance though.



Performance of linear algebra here is almost surely fixed by the underlying LAPACK library. Stock ATLAS is likely slowest, OpenBLAS or MKL are better, sometimes much better.



However, I'm pretty sure the main improvement here is indeed algorithmic. First, for PSD matrices Cholecky (cholesky/cho_solve) should be better. Second, you seem to be doing a rank-one update (x.T @x), and that can typically be implemented in N**2 operations via some variant of the Shermann-Morrison formula, instead of N**3 for direct inversion.






share|improve this answer





















  • I got it down to 1.3s with your advice! It was faster not to use Cholesky though. Do you have any other tips on how to make this go faster? Still quite slow given the number of repeats I need.
    – purpleostrich
    Nov 20 at 6:20











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53368838%2fspeeding-up-matrix-inversion%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










Stability-wise, it's almost always better to write solve(A, unit_matrix) instead of inv(A). That won't help with performance though.



Performance of linear algebra here is almost surely fixed by the underlying LAPACK library. Stock ATLAS is likely slowest, OpenBLAS or MKL are better, sometimes much better.



However, I'm pretty sure the main improvement here is indeed algorithmic. First, for PSD matrices Cholecky (cholesky/cho_solve) should be better. Second, you seem to be doing a rank-one update (x.T @x), and that can typically be implemented in N**2 operations via some variant of the Shermann-Morrison formula, instead of N**3 for direct inversion.






share|improve this answer





















  • I got it down to 1.3s with your advice! It was faster not to use Cholesky though. Do you have any other tips on how to make this go faster? Still quite slow given the number of repeats I need.
    – purpleostrich
    Nov 20 at 6:20















up vote
1
down vote



accepted










Stability-wise, it's almost always better to write solve(A, unit_matrix) instead of inv(A). That won't help with performance though.



Performance of linear algebra here is almost surely fixed by the underlying LAPACK library. Stock ATLAS is likely slowest, OpenBLAS or MKL are better, sometimes much better.



However, I'm pretty sure the main improvement here is indeed algorithmic. First, for PSD matrices Cholecky (cholesky/cho_solve) should be better. Second, you seem to be doing a rank-one update (x.T @x), and that can typically be implemented in N**2 operations via some variant of the Shermann-Morrison formula, instead of N**3 for direct inversion.






share|improve this answer





















  • I got it down to 1.3s with your advice! It was faster not to use Cholesky though. Do you have any other tips on how to make this go faster? Still quite slow given the number of repeats I need.
    – purpleostrich
    Nov 20 at 6:20













up vote
1
down vote



accepted







up vote
1
down vote



accepted






Stability-wise, it's almost always better to write solve(A, unit_matrix) instead of inv(A). That won't help with performance though.



Performance of linear algebra here is almost surely fixed by the underlying LAPACK library. Stock ATLAS is likely slowest, OpenBLAS or MKL are better, sometimes much better.



However, I'm pretty sure the main improvement here is indeed algorithmic. First, for PSD matrices Cholecky (cholesky/cho_solve) should be better. Second, you seem to be doing a rank-one update (x.T @x), and that can typically be implemented in N**2 operations via some variant of the Shermann-Morrison formula, instead of N**3 for direct inversion.






share|improve this answer












Stability-wise, it's almost always better to write solve(A, unit_matrix) instead of inv(A). That won't help with performance though.



Performance of linear algebra here is almost surely fixed by the underlying LAPACK library. Stock ATLAS is likely slowest, OpenBLAS or MKL are better, sometimes much better.



However, I'm pretty sure the main improvement here is indeed algorithmic. First, for PSD matrices Cholecky (cholesky/cho_solve) should be better. Second, you seem to be doing a rank-one update (x.T @x), and that can typically be implemented in N**2 operations via some variant of the Shermann-Morrison formula, instead of N**3 for direct inversion.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 19 at 20:14









ev-br

14.5k34166




14.5k34166












  • I got it down to 1.3s with your advice! It was faster not to use Cholesky though. Do you have any other tips on how to make this go faster? Still quite slow given the number of repeats I need.
    – purpleostrich
    Nov 20 at 6:20


















  • I got it down to 1.3s with your advice! It was faster not to use Cholesky though. Do you have any other tips on how to make this go faster? Still quite slow given the number of repeats I need.
    – purpleostrich
    Nov 20 at 6:20
















I got it down to 1.3s with your advice! It was faster not to use Cholesky though. Do you have any other tips on how to make this go faster? Still quite slow given the number of repeats I need.
– purpleostrich
Nov 20 at 6:20




I got it down to 1.3s with your advice! It was faster not to use Cholesky though. Do you have any other tips on how to make this go faster? Still quite slow given the number of repeats I need.
– purpleostrich
Nov 20 at 6:20


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53368838%2fspeeding-up-matrix-inversion%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

404 Error Contact Form 7 ajax form submitting

How to know if a Active Directory user can login interactively

Refactoring coordinates for Minecraft Pi buildings written in Python