| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Yeah, that's right that this is a problem why we cannot trace over the expectation functions but why not just using jax.lax.cond? I can take a look into it but this should be manageable that one just use that to make this traceable |
Sorry, something went wrong.
|
I also tried that, but true_func and false_func need to have the same dtype. Which is obviously not the case.
taken from https://openxla.org/xla/operation_semantics#conditional this is wrapped in jax.lax.cond |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
TLDR;
The idea of this PR is that we can maybe collect all the changes that are necessary to make the expectation functions traceable. Then we can jit a part of the __call__ method of the expectation function which would improve memory since jax also optimizes that under jit and it would allow us to checkpoint the computation of the expectation since it is very memory intensive to compute the RDM. I know there is also the checkpoint_ncon but this makes it more flexible.
the problematic part was this which is included in all expectation functions:
This construct performs a Python-level loop and uses JAX arrays in a dynamic control context, which prevents JAX from tracing or staging out the function properly.
Despite multiple workarounds, none of them integrated cleanly with JAX’s tracing model or yielded good memory behavior.
My proposal would be to remove all of these and let the user handle the dtype in the model they define. Since the result array is also only not big ~ num gates there should be no problem with the memory
A example from my code
AI SUMMARY
This pull request simplifies the three_sites.py module by removing the real_result logic from the _three_site_triangle_workhorse function and its associated callers. This streamlines the computation of expectation values for three-site triangles, ensuring consistent output regardless of whether the gates are Hermitian.
Refactoring and code simplification: