Feature/commutation check#12
Conversation
Benchmark Results (Julia v1)Time benchmarks
Memory benchmarks
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12 +/- ##
==========================================
+ Coverage 78.26% 81.54% +3.28%
==========================================
Files 4 5 +1
Lines 184 233 +49
==========================================
+ Hits 144 190 +46
- Misses 40 43 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Krastanov
left a comment
Krastanov
left a comment
There was a problem hiding this comment.
forgot to submit these comments originally, my bad. These are just preliminary discussion on style. Thanks for starting this!
| @@ -1,5 +1,9 @@ | |||
| # News | |||
|
|
|||
| ## underdevelop | |||
There was a problem hiding this comment.
What does "underdeveloped" mean? Unfinished or unreleased?
If it is "unfinished", let's just make sure we finish them in a well structured PR. If it is "unreleased", then put them with the rest in v0.1.0-dev which is also unreleased.
| using Moshi.Match: @match | ||
|
|
||
|
|
||
| function affectedpaulis(op::CircuitOp.Type) |
There was a problem hiding this comment.
Add a docstring to the function that explains what it is and what it is for. Use jldoctest to put in examples of how to use it.
| function complete_paulis(op1::CircuitOp.Type, op2::CircuitOp.Type) | ||
| pu1=affectedpaulis(op1) | ||
| pu2=affectedpaulis(op2) | ||
| println("Affected Paulis of op1: ", pu1) |
There was a problem hiding this comment.
Do not have your functions uncontrollably print things out -- that would make the library very very noisy and difficult to use without polluting the stdout. If these messages are valuable for you as you are working on the library, use @debug logging statements -- they can be controlled more easily and by default are quiet.
| end | ||
| end | ||
|
|
||
| function complete_paulis(op1::CircuitOp.Type, op2::CircuitOp.Type) |
There was a problem hiding this comment.
Docstring, as mentioned for the previous one. Check the julia documentation on how to structure docstrings.
|
|
||
| end | ||
|
|
||
| end No newline at end of file |
There was a problem hiding this comment.
Notice the warning about a missing new line at the end of this file. Set your editor to clean these things automatically. Here is the settings I have added to vscode for instance:
"editor.detectIndentation": false,
"editor.insertSpaces": true,
"editor.tabSize": 4,
"files.insertFinalNewline": true,
"files.trimFinalNewlines": true,
"files.trimTrailingWhitespace": true,
"editor.rulers": [92],
"files.eol": "\n",
Some of these might be redundant -- they have grown organically.
| @@ -1,5 +1,4 @@ | |||
| module PBCCompiler | |||
|
|
|||
There was a problem hiding this comment.
do not edit unrelated parts of the files, it makes the diffs noisy and more difficult to review
Bloooman
force-pushed
the
feature/commutation_check
branch
from
0c58ab2 to
0ee9ab8
Compare
2 participants
@Krastanov
Functions to check commutation between 2 Circuit Operations
Corresponding Tests for commutation checks
The code is properly formatted and commented.
Substantial new functionality is documented within the docs.
All new functionality is tested.
All of the automated tests on github pass.
We recently started enforcing formatting checks. If formatting issues are reported in the new code you have written, please correct them. There will be plenty of old code that is flagged as we are slowly transitioning to enforced formatting. Please do not worry about or address older formatting issues -- keep your PR just focused on your planned contribution.
If you are submitting for a bug bounty: