RFC: QuantumOperator

[amilsted]

So I spent a little time sketching some abstractions for quantum states and operators.

The intention is for this sort of thing to work:

# First, create a tensor network for your state.
# For example:
psi_node = Node(np.rand(2,2,2))  # pure state on 3 qubits
op_node = Node(np.rand(2,2))  # operator on 1 qubit

psi = QuantumKet([psi_node[i] for i in range(3)])

rho_1 = psi.reduced_density([2, 3])  # trace out sites 2 and 3
op_1 = QuantumOperator([op_node[0]], [op_node[1]])  # global operator on a 1-qubit space
expval = (op_1 @ rho_1).trace()

op_3 = op_1.tensor(QuantumIdentity(2))
expval = psi.adjoint() @ op_3 @ psi

print(contractors.greedy(expval.nodes).tensor)

print(contractors.greedy(expval.nodes).tensor)  # same result as above

...and so on.

It would be natural to also have FiniteMPS.as_quantum_state(), which would return a QuantumKet for the MPS network.

Thoughts?

By the way, for a natural representation of a local operator it would be good to allow Edges that are not attached to any nodes. Currently, this is not supported. I suppose one could use copy tensors instead...

Also, I realize one could drop the "quantum" terminology here (see "tensor trains"), but quantum is cool right now, so...

[chaserileyroberts]

I really like this!

Why do you need edges that are not connected to any nodes? Seems like you only use it for QuantumIdentity, which to me seems like you can just do np.eye(...) instead

[chaserileyroberts]

Please add this file as a PR with a pull request and add unit testing. We can discuss adding the "free" edges too, though do to some really hard assumptions I made that might be really difficult.

[amilsted]

Why do you need edges that are not connected to any nodes? Seems like you only use it for QuantumIdentity, which to me seems like you can just do np.eye(...) instead

Yes, this was for QuantumIdentity. I wanted to avoid explicitly building identity tensors (contracting with an explicit identity tensor adds a factor of the index dimension to the contraction cost!) and, since an edge is already an identity tensor, I was hoping just to have the same unconnected Edges in both in_edges and out_edges. Alternatively, we could have a dummy "identity tensor" Node type. The reason I mentioned copy nodes is because, for the a two-axis copy node, they are equivalent to identity tensors.

[amilsted]

@Thenerdstation @mganahl @MichaelMarien I am really wondering whether this should be "tensor-network linear algebra" abstraction rather than "quantum". Should I rename "Quantum" -> "TN" (TensorNetwork), "Operator" -> "Matrix"? Quantum sure is trendy, but the rename might make this more broadly accessible?

PS: How long before everyone realizes Quantum is just LinearAlgebra? ;)

[mganahl]

I'm in favor of the "TN" and "Operator" names, but I don't have a strong opinion.

[chaserileyroberts]

I have a weak prefence to "Quantum", but let's talk about it during our meeting this week

[chaserileyroberts]

Actually I changed my mind. I think we can just get rid of the word "quantum" in all of these and just use their secondary names exclusively. So QuantumKet -> Ket, QuantumOperator -> Operator. I think that would be best.

[amilsted]

At the moment I've settled on QuOperator etc.. I also added some blurb to justify:

Quantum mechanics involves a lot of linear algebra on vector spaces that often
have a preferred tensor-product factorization. Tensor networks are a natural
way to represent vectors and operators (matrices) involving these spaces. Hence
we provide some simple abstractions to ease linear algebra operations in which
the vectors and operators are represented by tensor networks.

[amilsted]

I am currently deciding how best to treat scalars (need to keep some reference nodes, since there are no dangling edges). After that, I'll submit a PR!

[MichaelMarien]

Thanks @amilsted, this looks like a great abstraction! No real opinion on the naming, as long as it doesn't scare away people / make them think these classes are only useful for quantum physicists!