Concretize Ansatz type with "lattice"/connectivity information and refactor subtypes on top of it

[mofeing]

Inspired by ITensorNetworks.jl (but not equal), I experimented with using a graph for representing the connectivity between different sites.

In "ITensorNetworks.jl", they use the graph for representing the structure of the TensorNetwork and the connectivity graph of the different sites, which is useful when dealing with lattices or hamiltonians. Unlike them, the hypergraph structure is already implicit in TensorNetwork, but it doesn't comfortably accommodate for fixed structured Tensor Networks like MPS, PEPS, TTN, ...

By adding a graph field in Ansatz that accounts for the connectivity pattern between sites, a lot of the software design problems can be mitigated.

I've also refactored Chain into MPS and MPO and Grid into PEPS and PEPO (actually, I've never seen a PEPO in real life).

@jofrevalles @starsfordummies you might want to reconsider refactoring your PR on top of this.

[mofeing]

@jofrevalles The code is basically finished and the tests have been refactored. I need to add some more tests, but the current tests are failing on comparing 2 Tensors with same content but different index permutation.

I thought this comparison should already be working (we have a isapprox implementation for that). Would you mind checking it please?

[jofrevalles]

I thought this comparison should already be working (we have a isapprox implementation for that). Would you mind checking it please?

It seems to be working for me:

julia> using Tenet

julia> rand_array = rand(2,2,2)
2×2×2 Array{Float64, 3}:
[:, :, 1] =
 0.305335   0.447022
 0.0377352  0.553704

[:, :, 2] =
 0.0825549  0.671104
 0.22955    0.801683

julia> A = Tensor(rand_array, (:i, :j, :k))
2×2×2 Tensor{Float64, 3, Array{Float64, 3}}:
[:, :, 1] =
 0.305335   0.447022
 0.0377352  0.553704

[:, :, 2] =
 0.0825549  0.671104
 0.22955    0.801683

julia> B = Tensor(permutedims(rand_array, (1, 3, 2)), (:i, :k, :j))
2×2×2 Tensor{Float64, 3, Array{Float64, 3}}:
[:, :, 1] =
 0.305335   0.0825549
 0.0377352  0.22955

[:, :, 2] =
 0.447022  0.671104
 0.553704  0.801683

julia> A == B
true

[mofeing]

@jofrevalles Seems like the problem is (again) related to the way indices are replaced when doing merge!. I thought it was a good idea, but we might want to rethink how to deal with indices on that case.

[jofrevalles]

@jofrevalles Seems like the problem is (again) related to the way indices are replaced when doing merge!. I thought it was a good idea, but we might want to rethink how to deal with indices on that case.

In my opinion, it would be much better to revert the code to what we had previously (so indices are not repeated, and just have an uuid). If we want to have "nice symbols" when doing plots, we can do some conversion or something before plotting in order to fix the labels.

[mofeing]

If we want to have "nice symbols" when doing plots, we can do some conversion or something before plotting in order to fix the labels.

I wouldn't change the indices for plotting because it will lie to the users.

[jofrevalles]

I wouldn't change the indices for plotting because it will lie to the users.

I mean, you can take any tn, and replace the indices with any mapping you want. For example, we could modify the internals so you could choose to use uuid for some situations, and "nice symbols" (using some kind of index counter as we had) in other situations.