Currently, when use sites/edges/etc. an iterator without any information of the lattice will be returned. This makes it less general and may cause type privacy while supporting the follow interface (useful when generating couplings):
We can have a wrapper iterator type for LatticeIterators
struct LatticeIterator{LTC, Iterator}
lattice::LTC
it::Iterator
end
and it will directly forward Base.iterate, Base.length, Base.size, etc. to LatticeIterator.it, but we can define rand(::Type{T}, ltc::LatticeIterator) = rand(T, size(ltc)) in general without any type privacy.
Boundary Conditions
[ ] all boundary condition will be defined inside module Boundary
[ ] Fixed -> Boundary.Open
[ ] Periodic -> Boundary.Periodic
[ ] boundary condition will has alias (NOTE: alias are always the lower case of the type name)
[ ] boundary keyword can use symbols
This will allow the follow syntax:
# module Boundary is exported, but not used
using Lattices
ltc = Chain(10; boundary=:open)
ltc = Chain(10; boundary=:periodic)
LatticeIterators sounds good, that way we can include info about the lattice, like boundary conditions, when generating couplings or on-site field terms.
Iterator API
surround
->neighbors
Iterator wrapper type
Currently, when use
sites
/edges
/etc. an iterator without any information of the lattice will be returned. This makes it less general and may cause type privacy while supporting the follow interface (useful when generating couplings):We can have a wrapper iterator type for
LatticeIterators
and it will directly forward
Base.iterate
,Base.length
,Base.size
, etc. toLatticeIterator.it
, but we can definerand(::Type{T}, ltc::LatticeIterator) = rand(T, size(ltc))
in general without any type privacy.Boundary Conditions
Boundary
Fixed
->Boundary.Open
Periodic
->Boundary.Periodic
boundary
keyword can use symbolsThis will allow the follow syntax:
@mbeach42 @crstnbr comments?