-
Notifications
You must be signed in to change notification settings - Fork 180
Conversation
* Clarify the restriction on the number of bits for IntAsBoolArray This should fix #166 by providing a more specific error message. * Update Standard/src/Convert/Convert.qs Co-Authored-By: Chris Granade <chgranad@microsoft.com> * Allow to have bits = 0 Looks like our tests assume that number = 0 with bits = 0 is a valid scenario; updating the change to account for that
* Two AND gate implementations. * Added test case. * Formatting. * Code formatting. * Update Standard/src/Canon/And.qs Co-Authored-By: Chris Granade <chgranad@microsoft.com> * Assertion for 0-target. * Added DOI to references. * Named application for CCNOTop. * Rename operations. * Add Test attribute. * Add links to arXiv. * Rename operations. * Better assertion for 0-target. * Fix bug in LowDepthAnd. * Docs. * Doc string convention. * Controlled variant for `ApplyAnd`. * Controlled AndLowDepth. * Adjoint Controlled LowDepthAnd. * References. * Simplify code. * Apply suggestions from code review Co-Authored-By: Chris Granade <chgranad@microsoft.com> * Integrate comment.
There appears to be no function IncrementByIntegerPhaseLE, and I guess it is covered by ApplyLEOperationOnPhaseLE. Co-authored-by: Chris Granade <cgranade@gmail.com>
* First work on Hadamard and SWAP test operations. * (c) header and typo fix. * Fixed typo with placement of phase shift. * Put public operations above private. * Added tests for new operations. * Added API documentation comments. * Newline at end of file.
* Began simplifying AA interface. * Expose traditional AA as new public operation. * Removed rest of "AmpAmp" prefix. * Resolve deprecation warning.
* Minor doc fixes * Minor doc cleanup There are probably still some unstated assumptions on the algorithms. * Add "# Description" for MultiplyByModularInteger ...because there is inline math. Co-Authored-By: Chris Granade <cgranade@gmail.com> * "unitary operation" instead of "unitary operator" Co-Authored-By: Chris Granade <cgranade@gmail.com> * Add "# Description", remove refs in "# Summary" Co-authored-by: Chris Granade <cgranade@gmail.com>
alan-geller
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.
Mostly I flagged several places in project files where you had deep (3+ level) upward relative paths, which I always find suspect; they may all be fine, but it's worth checking them carefully to make sure that VS or Code haven't snuck in a relative path that picks up something from another repo on your dev machine.
|
|
||
| <ItemGroup> | ||
| <PackageReference Include="Microsoft.Quantum.Development.Kit" Version="0.10.1912.501" /> | ||
| <ProjectReference Include="..\..\..\Standard\src\Standard.csproj" /> |
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.
Is this correct? I'm always suspicious of far-away upward relative paths.
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 path format followed throughout most of the libraries has been {library}/{src-or-tests}/{project}, such that going up three levels is unfortunately necessary for anything that crosses between libraries (e.g.: chemistry → standard).
| <Project Sdk="Microsoft.NET.Sdk"> | ||
| <Project Sdk="Microsoft.Quantum.Sdk/0.10.1912.2605-alpha"> | ||
|
|
||
| <Import Project="..\..\..\Build\props\tests.props" /> |
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.
Again, I'm always suspicious of far-away upward relative paths in project files.
| open Microsoft.Quantum.Oracles; | ||
|
|
||
|
|
||
| /// # Deprecated |
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.
Is there a reason why you don't want to use the system-generated message? You should get a deprecated warning for API documentation if you just have no doc comment at all but do have a deprecation attribute -- although I haven't actually tested this to make sure it works :-).
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.
Actually, if it doesn't work or doesn't do the right thing, we should fix it in docgen rather than have to work around it here.
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.
Ah, I was under the mistaken impression that both /// # Deprecated and @Deprecated("") were suggested for use together. In the upcoming code quality PR, then, I'll drop /// # Deprecated and leave it entirely to docgen so that we can assess if a fix is needed there.
| } | ||
|
|
||
| /// # Summary | ||
| /// Implements a multiple-controlled Toffoli gate, assuming that target |
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.
| /// Implements a multiple-controlled Toffoli gate, assuming that target | |
| /// Implements a multiple-controlled Toffoli gate, assuming that the target |
|
Thanks for the review, @alan-geller! If it's alright, I'd like to defer your suggestions to a separate PR since this PR currently only brings already accepted changes from master. That way I can avoid merge conflicts when it's time to bring the QML feature back onto master. I'm currently working on an all-up code quality PR using insights from the new experimental linter feature I've been playing with, such that I think your suggestions would fit great there. Thanks again for taking a look, I really appreciate it! |
* Improve code quality with experimental linter. * Fixed a couple mistakes in previous cleanup. * More fixes to resolve linting issues. * Remove extraneous comment. * Applied feedback from #198. * Applying more documentation fixes suggested by linter. * Fix to deprecation stub. * Whitespace fix noted by @ScottCarda-MS. * Fixed minor mistake introduced with previous code quality fix. * Incorporated more feedback from @ScottCarda-MS. * Update Standard/src/Arrays/Map.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Canon/Combinators/ApplyIf.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Canon/Combinators/ApplyIf.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Canon/Combinators/ApplyIf.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Arithmetic/Integer.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Arithmetic/Integer.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Canon/Combinators/ApplyIf.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Arithmetic/Integer.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Arithmetic/Integer.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Arithmetic/Integer.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Update Standard/src/Arithmetic/Integer.qs Co-Authored-By: Alan Geller <alan.geller@microsoft.com> * Addressing feedback, lots of indentation fixes. * Deprecate the stack data structure. * Slight improvements to phase est operations. * Add missing characteristics to CNOTChainTarget. * CCNOTChainTarget → ApplyCNOTChainWithTarget * Workaround for kata oracle counting. Co-authored-by: Alan Geller <alan.geller@microsoft.com>
This PR updates #176 to use recent PRs on master.