two methods of half-up #218
Conversation
…d the decoder shifter accordinly
…ing mathematica code. it was giving wrong operators before, now the operators are fine but signs are wonky
…to count qubit/fermion labels from 1 instead of 0
…ht) as a tool to append the same code intance several times
…sts for symbolicBinary. minor mods for python3 comp.
…ode, added an error if qubit index in a code is out of bounds
…ing by integer multiplication
…lf-up. Added tests for the codes.
… -> 0,2,4,..,1,3,...
|
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
|
With method (2), do InteractionOperator and InteractionRDM really need to "know its order"? I think we can just assume that the user will only evaluate expectation values for operators that use the same ordering; otherwise it's her own fault. Therefore I think method (2) should only require modifications to MolecularData. |
|
@kevinsung no they don't need to know 2) can have the same attitude towards user errors. With that assumption, would you rather 1 or 2? |
|
Agree with @kevinsung . |
|
I think 2 is more user-friendly so I say we go with that. |
|
I'll add that I don't think |
|
Actually, instead of |
|
what do you think of |
|
If we're going to go with a string I like Kevin's suggestion because it leaves no ambiguity as to what it does. |
|
ignore my last push - I failed at properly merging with my master. |
conta877
force-pushed
the
mergehalfup
branch
from
e3fc119
to
afcc830
Compare
|
Let me know when you're ready for review. |
|
ready!
…On Feb 25, 2018 19:57, "Ryan Babbush" ***@***.***> wrote:
Let me know when you're ready for review.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#218 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AV-mvHPMPdDrbXEm5rdjn3vVwCVDZMycks5tYiulgaJpZM4SSbUL>
.
|
* fixed bohr/angstrom confusion in function description * translations from mathematica to python arxiv1712.07067 * work on those notimplementeds * WIP: decoder class adittion * modified decoder class. extractor implemented * no need for pauliaction function * introduction of symbolic binary class - no more decoder class * minor bugs fixed, applies binary rules to input now * started programming the BinaryCode class, work in progress * added count qubit function in binary operator, modified code.py * fixed morning brain bugs * implemented concatination and appending, not yet documented and debugged * added _shift function to symbolicBinary and integer addition. modified the decoder shifter accordinly * radd imul, NOT TESTED! - just copy paste should work? * fixed small bugs, added default codes, created transform * fixed the multiplication error and modified the transform code following mathematica code. it was giving wrong operators before, now the operators are fine but signs are wonky * fixed the transform and all the places where we accidentally started to count qubit/fermion labels from 1 instead of 0 * bug fixes: ordering matters to detect which terms should cancel * fixed code appending, introduced the integer multiplication (left+right) as a tool to append the same code intance several times * modified the multiply by 0 and 1 behavior in SymbolicBinary. added tests for symbolicBinary. minor mods for python3 comp. * fixed the condition for code concatenation, fixed a bug in checksum_code, added an error if qubit index in a code is out of bounds * added comments to binary_operator, more test, evaluate function * started writing documentations and clipping lines, writing out numpy * merging with the merger * updating binary operator based on comments * updating the binary_ops * updates based on comments * init update * moved binaryop to first import * added names into notice and readme * started documentation in _code_operator.py, added parity code / (K=1) and (K=2) segment code / K=1 binary addressing code * encoders are sparse matrices now * added tests for code_operator * doc strings for the transform, fixed bug in the initialization of SymbolicBinary, made changes suggested by review, carried some of them over to files to be pulled later * updates based on pull request comments * merging changes with merger * fixing possible integer checking errors * cleaned version of transform function, needs testing and timing - seems to work so far * fixed BK transforms. indexing errors * added tests, pep8 and Ryan compliance mods * added some style to the functions file * renaming, re-structuring * renaming again * minor changes * pep8 * changed the symbolicBInary class * docstring cleanup * bug docstring fixes * bug fix in the evaluate method, pep8 the _binary_operator file * merge with upstream and additional tests to SymbolicBinary class * added weight-two segment code test, fixed bug with in the code appending by integer multiplication * added half-up code * bugs fixed in half-up code * corrected weight_one_segment_code and the interleaved_code, former half-up. Added tests for the codes. * get rid of heads * reordering function for the fermionOperator class. takes 0,1,2,3,4,.. -> 0,2,4,..,1,3,... * spin indexing within moleculardata * proper master reset
this pull request is more of a question
there are two implementations of half-up (#216),
a stand alone function in fermion_operator.py; half_up_order
modified get_molecular_hamiltonian function of MolecularData, which kinda spread from there -> InteractionRDM expectation needs to know the ordering of the InteractionOperator, that required the InteractionOperator to know its order. For now I only made expectation function raise NotImplementedError if InteractionOperator has half_up order, just because I am not sure which method we are gonna choose.
I am aware that 1) will cause the same problem with InteractionRDM but half_up_order function reordering feels less internal thus maybe its ok to not handle that.
Question is, which one do we want, do we want to implement this in another way?
Ryan edit: Closes #216