Comments (19)
I'm already working on this. If anyone is interested in collaborating/working together let me know.
from openfermion.
Awesome! Will translate to python. (probably won't happen before monday - in case someone else wants to work on it ASAP)
from openfermion.
Hi conta877, I was not aware that someone is already working on implementing my stuff to OpenFermion, but that's great. Can I help you?
from openfermion.
we've been working on my fork, so starting there could be helpful.
everything is living under simplifications for now and can be moved anywhere.
the code functions, but needs additional love and care.
there are two new operators,
symbolic_binary -> for decoder
code_operator -> (encoder,decoder) pair. [-- or (e,d) from the paper.]
the code_operator is used for the transformation.
_code_operator_transform.py has the transform function that takes a fermionOperator and a code and gives out the QubitOperator, corresponding to that code applied on the fermionOperator.
decoder_encoder_functions.py has sample codes
from openfermion.
Cool. I am at a conference right now and I believe one of the authors on that paper are also here. I will try to track them down and ask if they'd be willing to share any of their code.
I think it is important to note that while 1510.04048 seems easier to implement than the latter two papers, the technique has the unfortunate consequence of increasing the number of terms in the Hamiltonian exponentially. Thus, it is really only of academic interest at this point. The techniques introduced in 1701.08213 and 1712.07067 are efficient.
from openfermion.
Do feel welcome to discuss as much as possible on the thread, I think that's often helpful so people can understand design decisions, etc. But also no problem corresponding about some aspects privately.
from openfermion.
The papers I mentioned all introduce different approaches. Which are you working on?
from openfermion.
I wasn't working on any one of the papers mentioned above but after reading I'm thinking of switching to 1712.07067
from openfermion.
did you manage to track them down? are they willing to share?
from openfermion.
Yes! I spoke to Stephanie and Mark a few hours ago actually. Mark said that at this point the code is entirely in mathematica and that they actually distributed it on arXiv with the source, which you should be able to find here: https://arxiv.org/e-print/1712.07067 (you will need to change the file to another name with the extension .tar.gz). Mark also indicated that he may be interested in helping work on this.
from openfermion.
sorry - this is taking longer than I anticipated - if anyone wants to collaborate I keep my fork updated. for now introduced openfermion/simplifications not to break anything.
from openfermion.
Hi Mark, yes that would be awesome! I'll send you an email
from openfermion.
Design decisions time!
We have introduced a code_operator which is the (encoder,decoder) pair. One can define many transforms using the code_operator.
A logical place for this to live is under openfermion.transforms or codes can have their own folder.
We also have pre-defined transforms, checksum, segments (code_operator versions of JW,BK) and more can be added; so question is do we create separate file/test per transform or collect all transforms that use code_operator under one roof?
thoughts?
from openfermion.
This sounds cool. I'd like to understand a bit better though. Should I look at particular parts of 1712.07067 or your fork @conta877 ?
from openfermion.
Sorry I took so long to respond! I had to look through the paper again to make sense of what is going on with this but I've done that now. My vote is that we put this in transforms for now. It looks like some juicy pull requests are coming up. When you're ready, please try to make more small requests rather than one or two huge ones! It's much easier to review that way.
from openfermion.
Ok - I will release them one by one!
from openfermion.
@conta877 and @msteudtner have made some excellent contributions towards this issue. Do you two feel there are interesting methods to implement along these lines that would be low hanging fruit? If not, perhaps we should "close" this issue for now? What do you think?
from openfermion.
now that the tools are there we can always add new "code". if we decide to implement a completely different method we can reopen the issue maybe?
from openfermion.
Yep, I think that sounds like a good plan. I will close the issue then. Thanks!
from openfermion.
Related Issues (20)
- Incorrect Bounds on Trotter Error
- Incorrect formula to calculate required Trotter steps HOT 1
- Resource estimation code not tested as part of the CI
- Should move to black for formatting.
- Why does MajoranaOperator not subclass SymbolicOperator? HOT 1
- Some inconsistencies in molecular single factorization costings HOT 1
- Inconsistencies in the double factorized chemistry resource estimate costing function
- 91 tests fail HOT 7
- Nightly tests are broken HOT 1
- slight modification to function generate_hamiltonian ?
- Operation between MajoranaOperator and numbers? HOT 5
- QuadraticFermionicSimulationGate tests fail with cirq == 1.3.0 HOT 5
- Hubbard model notebook is flaky
- Trotter evolution time may be off by a factor of 2 HOT 2
- 1 test fails HOT 1
- get_sparse_operator fails on non-simplified QubitOperators
- Bad behavior when working with sympy
- pip installation overwrites module directory HOT 5
- Suggestion: add GitHub topic tag 'cirq' to repo
- Newer versions of jax introduce breaking change when import jax.config HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openfermion.