qfortecon Spring 2021

[fevangelista]

TODOs

Global

• Replace the many terms methods and functions with more specific names (Too Many Terms #60)
• Make pip package
• Standardize names of print functions. smart_print should be print.

Local

• Create a nice image that shows qubit ordering/operator ordering convention
• Support qubit-to-fermion transformations other than JW
• Add code to handle fermionic quantum computer
• Print only QuantumComputer elements that are nonzero. (Nan)
• Support frozen core and virtual for Psi4. (Support Frozen Core from Psi4 Molecules #62)
• Do we want to keep the Openfermion adapters? They end up going through Psi4 anyways.
• A user should be able to switch from shot-based computations to "exact" computations with a single line of code.

Changes made

Global

• Class renaming (Rename Sq and Quantum to Fermion and Qubit #57)
• Shorten names, e.g., QuantumComputer -> QubitComputer/QComputer/Computer? (Nick)
• Avoid passing control gate id in make_gate for single qubit operators. (Francesco, see PR Rename make_gate and make input more friendly #83)
• Generalize handling of sq operators (non-particle conserving) (Non-Particle-Conserving Fermion Operators #58) (Jonathon)
• Implement __str__ on the C++ side to avoid having to do print(obj.str()) [want to achieve this: print(obj)] (Francesco, see PR Add string representation (__str__,__repr__) to all classes exposed. Add pull request template. #84)
• All external codes used in adapters should be removed as hard dependencies, only used for those specific adapters.
• Nick should revamp the reference system. We should probably just assume the HF reference for all cases.
• Pass unitary that prepares the reference state (or a reference state).(Nick)

Local

• Can we catch passing in the same qubit for control and target for two qubit operators? (there are already checks in place for this. Calling qforte.gate('CNOT',0,0) returns type = CNOT with target = 0, control = 0, parameter = 0 + i0 is not a valid quantum gate in PR Rename make_gate and make input more friendly #83)
• Can we pass a list of gates to the QuantumCircuit constructor, to bypass add_gate?
• Can we support add for any (Nan, PR Change all add_* functions to add, modify all related protocol #88)
• Reverse printing of operators? (Nan)
• Rename exponentiate_single_term to exponentiate_pauli_string if it requires Pauli strings only (Francesco, PR Rename exponentiate_single_term() to exponentiate_pauli_string() #100 .

[JonathonMisiewicz]

Wait, what's a "fermionic quantum computer"?

[JonathonMisiewicz]

For the sake of coordination, my personal QForte to-do list is:

• Submit PR in progress to remove code duplication between VQE and PQE.
• Finish class renaming, Rename Sq and Quantum to Fermion and Qubit #57

After that, I'm not sure what my next QForte project will be. If you are going to take an issue, please say so, so no effort gets duplicated.

[fevangelista]

Is someone working on "Can we pass a list of gates to the QuantumCircuit constructor, to bypass add_gate?" or is this already a working feature?

[nstair]

Is someone working on "Can we pass a list of gates to the QuantumCircuit constructor, to bypass add_gate?" or is this already a working feature?

It is already a working feature, but uses a function rather than an overload of the constructor. Nan added it some time ago. Syntax looks like qforte.build_circuit('X_1 Y_2 X_3 Y_4').

[fevangelista]

It would still be useful to support the following:

g1 = qforte.gate(...)
g2 = qforte.gate(...)
circ.add([g1,g2]) # or circ.add(g1,g2)

[JonathonMisiewicz]

I can take non-particle-conserving SQ operators and excise unused code as I see it.