Quantum circuit and state models for IR integration

[Mandrenkov]

Context:
This PR is part of an ongoing series of changes to integrate the XIR with Jet.

Description of the Change:

• An abstract State class has been added to model quantum states.
  • This includes Qudit and QuditRegister implementations of State.
• A Circuit class has been added to model the connectivity between quantum states and gates.
  • The main purpose of this class is to transform a quantum circuit into a tensor network.
  • A new Wire class has also been created as a byproduct of the Circuit implementation.
• The gates.py file has been renamed to gate.py for the sake of consistency.

Benefits:

• XIR scripts with amplitude outputs can be trivially converted into tensor networks.
• Users can leverage Jet to simulate a quantum circuit without any domain-specific knowledge of tensor networks.

Possible Drawbacks:

• Additional documentation will be needed for users that wish to use the quantum abstractions in the jet package.

Related GitHub Issues:
None.

[Mandrenkov]

Thank you again for the review, @josh146! Let me know if any of my answers to your questions are unsatisfactory.

[mlxd]

Great work on this. Minor comments, that can be ignored if they add nothing.

[brownj85]

Hey Mikhail, good work on this. I have a few questions/suggestions around the Circuit class, I'm going to take a closer look at the State part after.

[trevor-vincent]

Hey Mikhail, I really like this design/naming conventions.

One thing and this is just about making it possibly future-proof - do you think it will be easy to incorporate in this design "non-wire" connections between operators/gates in the circuit? Maybe we can call these "bonds" as this is what they are called in the specific case of Matrix Product State representations. These prop up for Krauss operations and Matrix Product State representations of Gates.

Also, I'm assuming it will be easy to incorporate in this design, adjoint operators/gates which are needed in almost every non-amplitude type calculation (e.g. sampling, local expectation,...) as well as in mixed-state simulation. These are just connections on a wire anyway, so I assume they can be easily incorporated here.

If you think these things will break this design in a major way, maybe we should fit them in now?

[Mandrenkov]

Hey Mikhail, I really like this design/naming conventions.

Cheers!

One thing and this is just about making it possibly future-proof - do you think it will be easy to incorporate in this design "non-wire" connections between operators/gates in the circuit? Maybe we can call these "bonds" as this is what they are called in the specific case of Matrix Product State representations. These prop up for Krauss operations and Matrix Product State representations of Gates.

Yeah, I gave this some thought while implementing the Circuit class and reached the conclusion that the best way to do this is to implement another append function (e.g., append_loss) which behaves much like append_gate but with an index fix that occurs during the call to adjoint() described below. This pattern should work for any "part" which only needs a skip connection to its adjoint.

Also, I'm assuming it will be easy to incorporate in this design, adjoint operators/gates which are needed in almost every non-amplitude type calculation (e.g. sampling, local expectation,...) as well as in mixed-state simulation. These are just connections on a wire anyway, so I assume they can be easily incorporated here.

My current plan is to implement a class method adjoint() which accepts an observable and a set of wire IDs as input and appends the observable as well as the adjoints of the parts which were appended to the circuit in reverse order, effectively "closing" the circuit. We can also fix the indices of any loss operators in this function.

If you think these things will break this design in a major way, maybe we should fit them in now?

Yes but fortunately I think the current design should be flexible enough to support our foreseeable needs 🙂. We can always iterate on this later if we find a major design flaw.

[brownj85]

Looks good Mikhail, just one suggestion on state.py, though if you merge as-is that would be fine.