You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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} <:Quantumwhere {P<:Plug,B<:Boundary} end
would be rewritten as
abstract type Ansatz endstruct MatrixProduct{P<:Plug,B<:Boundary} <:Ansatzend
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/
The text was updated successfully, but these errors were encountered: