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
numpy optimization scipy statistics
add a comment |
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
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 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 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
add a comment |
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
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 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 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 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
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 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 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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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 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
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 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
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.
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.
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 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