Marquess Valdez
Marquess Valdez
@bramathon curious what you think about this proposal. Are the limitations workable, or would you need a solution for them before this could really be adopted?
This has to do with how `quil-rs` stores parameters. Currently, it upcasts everything to a complex number since it is sufficient for representing all number types. I can look into...
I've done some testing on this in preparation for v4, and right now, threading is still favored. pyQuil doesn't offer an `asyncio` API and so it doesn't offer much benefit....
This has been fixed in v4, [with the appropriate amount of nuance](https://pyquil-docs.rigetti.com/en/v4/introducing_v4.html#accessing-raw-execution-data).
Hey @vtomole! This PR is ready to review from our perspective. Anything else you need us to do?
`sum` uses the `__add__` method, so it's not taking advantage of the optimizations we implemented for #1647. A loop that uses the += operator should be faster. Alternatively, you could...
4.0.1 includes optimizations from `quil` that should improve the performance of in-place addition even further.
> To be transparent, I am hesitant about the approach for these reasons: > > * in our migration to Rust and pyQuil v4, we intended to leave pyquil "as-is"...
This is intended behavior inherited from `quil`. Does this cause a problem?
For now at least, this is intended behavior on the part of `quil-rs`.