Closed charlesyuan314 closed 1 month ago
@mpharrigan @tanujkhattar @fdmalone Do you think this is a sane approach?
P.S. Looks like I can't directly request a PR review without being a member of the quantumlib
org.
I think this makes sense. The bigger migration might be to just replace iter_bits with the corresponding to_bits methods from the register data types(e.g. https://github.com/quantumlib/Qualtran/blob/main/qualtran/_infra/data_types.py#L215) which will handle the signed-ness etc. But maybe out of scope for this PR.
Yeah, since this one of the issues with this consolidation (as currently presented) is that it drops the data-type-specific configuration options (signedness, input validation...) that are now encoded in the QDType
implementations (which didn't exist when all these iter_bits functions were first introduced).
Can you find where these methods are used within the library and see if it would be sensible to replace them with e.g. QUInt(...).to_bits(x)
? And maybe port these free functions to use the qdtype methods under-the-hood but with a backwards-compatible interface
Closing as I'm currently working on a PR to replace the bit_tools
functions with QDType
implementations as @mpharrigan suggested.
This is just a first attempt at #811 to gather feedback and to see what tests fail.
Known issues:
iter_bits
still exists even though it is entirely redundant.iter_bits
no longer supports sign.iter_bits
no longer raisesValueError
for too-wide inputs.