Using type-parameters for encoding TN ansatz is not going to scale well.
Composite incurs in a lot of compilation.
Runtime dispatch is more costly than conditionals.
Proposal
The idea is to replace MatrixProduct, ProjectedEntangledPair, ... for Holy traits.
abstract type MatrixProduct{P,B} <: Quantum where {P<:Plug,B<:Boundary} end
would be rewritten as
abstract type Ansatz end
struct MatrixProduct{P<:Plug,B<:Boundary} <: Ansatz end
Also, the current Ansatz type would be renamed, because it would no longer express what we are meaning about it (i.e. the form of the graph). I suggest renaming it to Domain because that's what its fields are going to vary on.
Using type-parameters for encoding TN ansatz is not going to scale well.
Composite
incurs in a lot of compilation.Proposal
The idea is to replace
MatrixProduct
,ProjectedEntangledPair
, ... for Holy traits.would be rewritten as
Also, the current
Ansatz
type would be renamed, because it would no longer express what we are meaning about it (i.e. the form of the graph). I suggest renaming it toDomain
because that's what its fields are going to vary on.Links
https://invenia.github.io/blog/2019/11/06/julialang-features-part-2/ https://www.ahsmart.com/pub/holy-traits-design-patterns-and-best-practice-book/