Hi,
I was wondering if it would be possible to have ITensors.Ops support a single index? I envision writing a Hubbard term as follows:
using ITensors, ITensors.Ops
s = ITensors.siteind("Electron")
ITensor((Op("Nup")-Op("I")/2)*(Op("Ndn")-Op("I")/2), s)
At the moment, the closest I got is
ITensor((Op("Nup",1) + -0.5*Op("I",1))*(Op("Ndn",1) + -0.5*Op("I",1)), [s])
which is OK, but would be nice if one can avoid indexing when using a single site.
More generally, isITensors.Ops something that I should rely on in the long run? I believe I saw a previous question about documentation, and I was generally wondering about examples, but so far, I have had to go to the code.
Thanks!
It’s not really meant for public consumption right now, however the basic functionality including operations in the example you wrote (i.e. basic linear algebra and conversions) should remain stable. The issue is that right now that module is somewhere between a full-fledged symbolic operator algebra library and a private tool to serve the MPO conversion code, and I didn’t have time to really turn it into a library that I felt comfortable making public.
Part of the reason why it isn’t public is that I wasn’t very happy about the way we represent the operator type and expressions, and since writing it we have learned more about writing symbolic algebra systems. We’re working on a rewrite that will be a standalone library that will have a better design based on sum types/algebraic data types but I don’t know when it will be ready. In our current plan we’ll have a representation of operators that don’t have sites attached but that will likely be a different type, I think we might call it a LocalOp (along with a type like Op that has sites attached). The better design we have planned will make it easier to support more ambitious features like automatic differentiation, arbitrary nested expressions, symbolic support for fermions and non-abelian operators, multi-site operators, operator rewrite rules and expression simplifications, symbolic compression of operator sums into symbolic MPOs/TTNOs, etc.
OK, thanks, that was my impression, and the plans sound promising.
So for now, I will use it at my own risk and adapt as things change.