Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add on_error argument to linalg functions #1078

Open
jessegrabowski opened this issue Nov 11, 2024 · 6 comments
Open

Add on_error argument to linalg functions #1078

jessegrabowski opened this issue Nov 11, 2024 · 6 comments
Labels

Comments

@jessegrabowski
Copy link
Member

Description

Our implementation of Cholesky has a nice argument on_error that lets the user get back nan from an bad input instead of halting the program. This would be a nice feature to have in other places where shoving in random matrices (pun intended) can be dangerous. I'm thinking specifically about pt.linalg.solve, but I kept the issue name generic in case we think of others.

The fix itself is trivial: add a try/except around the perform method of e.g. solve. The only wrinkle I foresee is what to do with the gradients.

@ricardoV94
Copy link
Member

The only wrinkle I foresee is what to do with the gradients.

Do we do anything on the Solve?

@jessegrabowski
Copy link
Member Author

On CholeskySolve you mean? Or just solve generally?

Right now if pt.linalg.solve fails (for example because you pass a low-rank matrix) the program crashes with a LAPACK error

@ricardoV94
Copy link
Member

ricardoV94 commented Nov 11, 2024

Sorry I meant on the Cholesky that has this special behavior implemented. Do we do anything different on the gradient in the case of on_error="nan"?

@jessegrabowski
Copy link
Member Author

jessegrabowski commented Nov 11, 2024

Yeah it gets replaced with a scalar 1 to allow some intermediate computation, then returns a matrix of nan in the end.

@ricardoV94
Copy link
Member

So it returns nan, and it has the work-around for Solve. If Solve returned nan, it wouldn't need the work-around?

@ricardoV94
Copy link
Member

This would also allow us to remove this switch logic in the multivariate logp: https://github.com/pymc-devs/pymc/blob/f5517186874107e72440ec9b55cd31ce77cc2a3d/pymc/distributions/multivariate.py#L181-L183

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants