Speeding Up Matrix Inversion
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
add a comment |
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
3
Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
– Paul Brodersen
Nov 19 '18 at 9:38
1
Sure thaty
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 '18 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 '18 at 19:14
@joni I added some sample data, thank you!
– purpleostrich
Nov 19 '18 at 19:36
add a comment |
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
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
numpy optimization scipy statistics
edited Nov 20 '18 at 6:19
purpleostrich
asked Nov 19 '18 at 5:33
purpleostrichpurpleostrich
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 '18 at 9:38
1
Sure thaty
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 '18 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 '18 at 19:14
@joni I added some sample data, thank you!
– purpleostrich
Nov 19 '18 at 19:36
add a comment |
3
Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
– Paul Brodersen
Nov 19 '18 at 9:38
1
Sure thaty
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 '18 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 '18 at 19:14
@joni I added some sample data, thank you!
– purpleostrich
Nov 19 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 at 19:14
@joni I added some sample data, thank you!
– purpleostrich
Nov 19 '18 at 19:36
@joni I added some sample data, thank you!
– purpleostrich
Nov 19 '18 at 19:36
add a comment |
1 Answer
1
active
oldest
votes
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.
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 '18 at 6:20
add a comment |
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',
autoActivateHeartbeat: false,
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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 '18 at 6:20
add a comment |
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.
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 '18 at 6:20
add a comment |
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.
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.
answered Nov 19 '18 at 20:14
ev-brev-br
14.8k34367
14.8k34367
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 '18 at 6:20
add a comment |
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 '18 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 '18 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 '18 at 6:20
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
3
Are you 100% positive that you really need to invert those matrices? People generally try very hard not to.
– Paul Brodersen
Nov 19 '18 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 '18 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 '18 at 19:14
@joni I added some sample data, thank you!
– purpleostrich
Nov 19 '18 at 19:36