-
Notifications
You must be signed in to change notification settings - Fork 10
test: Add some example guppy-generated hugrs #904
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
Conversation
|
58623d5 to
1ccc8ac
Compare
|
|
1696695 to
2dde95a
Compare
fdb1dbf to
2f43126
Compare
acl-cqc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @aborgna-q ! Nice, mostly just inconsistencies in the README... and that versionning question
|
|
||
| @guppy | ||
| def main() -> None: | ||
| pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is that the measurements are not returned here?? I mean, if so couldn't we elide any series of gates if we are not doing anything to measure them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right!
I added a result(.., measurement(q)) side-effect to all the scripts, so they don't get DCE'd.
|
|
||
| Each example here contains: | ||
| - A `.py` file that defines the guppy program | ||
| - If possible, a `.flat.py` file that defines the same program using `comptime` or manual loop peeling. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You say "if possible" - and all examples have one except "simple_cx" - I don't see any reason why one couldn't define even that program using comptime - do you mean "if different"? (if the Hugr result is different, if the result of optimization is expected to be different?)
Or, perhaps we should just include a simple_cx_flat using comptime ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll leave this for when we implement the tests. We can add the missing one if required.
| Each example here contains: | ||
| - A `.py` file that defines the guppy program | ||
| - If possible, a `.flat.py` file that defines the same program using `comptime` or manual loop peeling. | ||
| - A `.opt.py` file that defines the optimized version of the program, which we |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually mean we expect identical Hugrs (the original optimized by compiler, and the hand-one without compiler optimization)?
I might just say "a hand-optimized version" and then (perhaps depending on what you mean here) "indicative of the greatest optimization we believe can be achieved"
| @# Find all examples in subdirectories and re-run them. | ||
| for example in $(find . -type f -name "*.py"); do | ||
| echo "Re-generating $example" | ||
| uvx --with 'guppylang==0.21.2' python "$example" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably (inferring from, rather than finding in, the docs) this means guppylang does not need to be installed?
I expect that at some point we will want to have multiple .hugr files for different guppy versions. So I'm wondering whether we should include the version in the .hugr filename starting now. If you think it'll be ok to add this in a later PR, then ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the version here and added uv script headers on each file instead.
Now each example defines the guppy and python versions it needs.
|
|
||
|
|
||
| program = main.compile() | ||
| Path(argv[0]).with_suffix(".hugr").write_bytes(program.to_bytes()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative might be to write the bytes to stdout and for justfile to redirect them to a computed filename. (Avoids some duplication of output-filename-computation, but indeed writing bytes to stdout is a bit messy!) This might be better if we want to include guppy version in the filename, as per other comment...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I though about having a utils.py file too, but that's problematic when you have standalone python files.
Co-authored-by: Alan Lawrence <[email protected]>
acl-cqc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice @aborgna-q! Thanks :).
Like the scheme where the /// script specifies the version for each example.
One thought - do we actually want to check the .mmd's in? Seems like it introduces extra variation/fragility from the mermaid-generator; if the hugr hasn't changed but the mermaid has, we probably don't care here, and if the hugr has changed but the mermaid hasn't, well, thankfully the hugr having changed will probably make some noise ;). Otherwise, we could just .gitignore them?
| echo "Re-generating hugr diagrams" | ||
| cargo install hugr-cli | ||
| # Find directories containing a `.generate_mmd` file | ||
| for dir in $(find . -type f -name ".generate_mmd" -exec dirname {} \;); do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
snazzy!! 👍
|
Added the |
Add test pass runs over the circuits from #904. Some notable issues: - The constant folding pass (and DCE) fails on some cases, leaving unconnected qubit ports. Quantinuum/hugr#2557 Should be fixed on Quantinuum/hugr#2560 - (Requires Hugr `0.22.4` / `0.23` release) - The basic-block merge rewrite should define a composable pass. Quantinuum/hugr#2556 - We are missing a simple `InlineCFG` pass to unwrap simple linear CFGs. (Either single blocks, or it can be conbined with `merge_bbs`). Quantinuum/hugr#945 If we fix those, we should be able to `assert!` that some of the examples here optimize to the identity. We'll need to call pytket optimisations for the rest. - ~Requires a `hugr 0.22.3` release with this fix: Quantinuum/hugr#2549 - Requires #1118
Adds guppy program examples described by @cqc-alec in Quantinuum/hugr#2246.
These are example programs intended to test compiler passes internally. We are not interested in testing guppy here but rather programs that resemble guppy's compilation output in their structure, hence why we use a pinned guppy version and don't enforce the artifacts to be up-to-date.
We also generate
.mmdmermaid diagrams if the example defines a.generate_mmdmarker file.