Using symmetries to reduce qubit requirements about openfermion

[conta877]

I'm already working on this. If anyone is interested in collaborating/working together let me know.

[conta877]

Awesome! Will translate to python. (probably won't happen before monday - in case someone else wants to work on it ASAP)

[msteudtner]

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?

[conta877]

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

[babbush]

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.

[babbush]

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.

[babbush]

The papers I mentioned all introduce different approaches. Which are you working on?

[conta877]

I wasn't working on any one of the papers mentioned above but after reading I'm thinking of switching to 1712.07067

[conta877]

did you manage to track them down? are they willing to share?

[babbush]

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.

[conta877]

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.

[conta877]

Hi Mark, yes that would be awesome! I'll send you an email

[conta877]

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?

[babbush]

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 ?

[babbush]

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.

[conta877]

Ok - I will release them one by one!

[babbush]

@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?

[conta877]

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?

[babbush]

Yep, I think that sounds like a good plan. I will close the issue then. Thanks!