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

Enhancements that could be made to the QVM testing framework #4

Open
5 tasks
fvoichick opened this issue Jul 22, 2021 · 0 comments
Open
5 tasks

Enhancements that could be made to the QVM testing framework #4

fvoichick opened this issue Jul 22, 2021 · 0 comments

Comments

@fvoichick
Copy link
Contributor

As Mike suggested, I'm creating a GitHub issue for things that could be done to improve QVM.

  • A full proof of Grover's correctness with a single conjecture hole. Currently, there are SQIR proofs showing that Grover's algorithm is correct given oracle behavior, and there are QVM tests that validate oracle behavior. However, these are still somewhat disconnected. It would be nice if we had a full end-to-end proof that "this instantiation of Grover's algorithm inverts this hash function." This proof should depend on a single conjecture that is QuickChickable.
  • Performant data types. Right now, the semantics of QVM are defined in terms of natural numbers and functional maps. Sometimes, natural numbers are used to represent values that will be very large, like an input number to an addition circuit. Whenever nat is used for a value that will be very large, and it's relevant to semantics or something that will be run in tests, then binary representations of numbers should be used, like N or positive. Functional maps can also eat up a lot of memory and time, so using FMaps for maps relevant to the semantics would be good. If we really want good performance, we could use positive instead of nat to represent variables, and then use PositiveMap.
  • Testing at the QIMP level. We will definitely get much better testing performance if we can do things like addition using Coq functions rather than running circuits. However, we don't (yet) have verified compilation from QIMP to PQASM, so we won't be able to draw as many conclusions from testing results.
  • Better utilities for automatically computing parameters to the various compilation and semantic functions. I found it very difficult to figure out what values should be in the maps that I'm passing to the various compilers, and the documentation is lacking. A lot of them can be automatically generated, and some clearer and simpler usage examples might be nice.
  • Maybe part of the first one, but better reasoning about the relationship between PQASM semantics and SQIR semantics. Obviously, we have the verified compiler, and the verification of this compiler depends on this relationship already. However, it would be nice if PQASM semantics could be more directly translated into the kinds of propositions currently used in the proofs of correctness of algorithms.
@khieta khieta transferred this issue from inQWIRE/SQIR Nov 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant