pipme

@patel-zeel I have a fixed version and may be able to make a PR later this week after some testing with batches etc.

Hi, thanks. The `log_normal` is an attribute of a class instance that need to be deep copied. A workaround may be using `log_normal.copy()` and writing a custom deepcopy method. But...

I just saw `clear_backend()` here and it turns out to be quite useful. https://github.com/google/jax/blob/7721579700ee5c4a951e72156a0bdac4c9768f43/jax/_src/api.py#L3250-L3264

@sokrypton I guess you need to call `jax.clear_backends()` periodically.

Hi, I changed the `tol` from `1e-3` to `1e-5` and now the test is passed.

In the meantime for anyone who wants a quick workaround, I [hard-coded a `ctrl-o` shortcut](https://github.com/pipme/zotero-markdb-connect/commit/b954ab719f2808b9b44b231bca97bf996e2bbeef) with the release here https://github.com/pipme/zotero-markdb-connect/releases/tag/v0.0.24, which seems to work fine.

Hi @Balandat, thanks for the reply. Maybe I was unclear in the description. Actually I wanted to fit SGPR with traditional *exact* computations (Cholesky decomposition). Therefore the modifications by botorch...

> the difference is due to the approximate log-probability computations of 13279-dim MVN Thanks for figuring it out. In this case, doesn't it mean that GPyTorch didn't implement SGPR properly?...

Something mysterious: when I called `jax._src.api.clear_backends()`, the program ran into an out-of-memory issue after a while. If I instead commented `clear_backends` out, it ran without a problem. Also, it seems...

For reference, the current solution with ruff v0.2.2 in VS Code is to set: `"ruff.format.args": ["--config", "line-length=79"]`