Adding Type2 Targeting Package #353
Conversation
|
I'm working on the test infrastructure right now, but figured I'd start the draft to potentially get feedback on some of the names and file structure. The simulator work for testing is going to take some time, but if I do it the longer way it would enable executing projects compiled against this package, which seems worth it. |
| /// ## qubits | ||
| /// Register to apply the given rotation to. | ||
| @EnableTestingViaName("Test.TargetDefinitions.Exp") | ||
| operation Exp (paulis : Pauli[], theta : Double, qubits : Qubit[]) : Unit is Adj + Ctl { |
There was a problem hiding this comment.
@alan-geller Here is an example of what we were talking about on the other thread: an alternate definition of Microsoft.Quantum.Intrinsic.Exp that is based on the Ising rotation gates. To differentiate, I named the file ExpFromIsing.qs. I'm definitely open to suggestions regarding naming patterns, too. I did consider trying to keep the names simple and putting related files in subfolders together (for example, ExpFromIsing.qs would go with ExpFracFromIsing, IsingXX, IsingYY, and IsingZZ), but that kind of approach can quickly lead to overly complex hierarchies of folders, especially when some files are shared among only slightly related definitions. It's also possible to imagine a target definition for a system that has only one of the rotations, say IsingXX, and then the overlap among files would again be confusing. For those reasons, I thought keeping a single folder with flat hierarchy and using filenames to disambiguate seemed the least prone to overcomplexity.
There was a problem hiding this comment.
I agree, keeping things flat is simpler, assuming we can make it work. While I can certainly imagine almost insane amounts of complexity, I suspect in real life the number of cases that come up are more limited.
|
|
||
| <PropertyGroup> | ||
| <Authors>Microsoft</Authors> | ||
| <Description>Type2 Targeting support for the Q# programming language.</Description> |
There was a problem hiding this comment.
@alan-geller This is the project that I imagine would participate in your new rewrite step, since it would be responsible for establishing the base classes that need to be implemented for Type2 targeting compatibility.
There was a problem hiding this comment.
Actually, thinking about it more, we would eventually want every targeting package, including QsharpCore, to use that rewrite step as the means for hooking into the simulation and/or translation infrastructure. This is just the first non-default target.
swernli
force-pushed
the
swernli/decomp-type2
branch
from
116f9e3 to
988aac8
Compare
This change makse it so that C# generation for references that have a test name attribute only happens when loading via test names is requested.
|
I'm working on getting the previous set of accumulated changes from the working branch into the feature branch (see #358 ), and once that is ready I should be able to rebase this branch and retarget this PR into the feature/decomp branch. At that point it will be ready for a real review. |
|
Closing this in favor of a PR into the feature branch. |
|
See #363 |
This adds a Type2 targeting package based on the set of native operations expected to be supported on Type2 architecture. This includes:
Removal of some leftover deprecated diagnostics operations from QsharpCore
The addition of intrinsic and decomposition definitions for Type2
Creation of a Type2Core that wraps and compiles the Type2 package (no implementation, just abstract intrinsics).
Test infrastructure for validating targeting packages against QsharpCore (via custom simulator support).