Observations about Hilbert spaces

Here are various observations, roughly in order of importance that I attach to them. Please comment.

I think that we should try to make the interface purely vectorized. That means that if we keep a separate Site class it should be a subclass of SiteArray and only exist for user convenience. The API would always deal with site arrays. For now, I think we could simply get rid of Site.

It seems to me that we can require that sites in an array are always sorted. That simplifies various algorithms and improves their performance. Furthermore, it allows to adopt run length encoding compression for site arrays which is something I believe we should do eventually.

I think that we don't need direct sums, because we can have operators that act between different Hilbert spaces and we can have operators that are sums of operators. Not having direct sums means that each Hilbert space is a direct product of fundamental Hilbert spaces. This greatly simplifies indexing without, it seems, introduing any problems.

I think that it's a good idea to separate fundamental Hilbert spaces into separate purley Finite and Infinite ones. I was first thinking about having a single Fundamental class, but that would make direct products more complicated. I think that we can further regularize things by requiring that each fundamental Hilbert space (i.e. Finite or Infinite) has a name that defines its identity. The names would be kept unique by storing a hidden weakref.WeakValueDictionary that maps names to the instances. Now a direct product space would hold two lists, one for its constituent finite spaces and one for the infinite ones. In each list the spaces would be sorted by their names. This way, we can define a direct product between any two Hilbert spaces and it's no longer necessary to require that infinite ones come first.

I current Kwant, we chose to use __call__ to obtain sites from site families. I think the reason was that syst[lat(1,2), lat(2,3)] looks nicer than syst[lat[1,2], lat[2,3]]. But now it might be better to use square bracket indexing, since this would allow us to introduce fancy indexing à la NumPy, e.g. sites = space[:, 0:10, 0:10] or sites = space[array_of_tags].

How about renaming HilbertSpace to StateSpace or even simply Space? The module could be also simply named space. Keeping Hilbert is a bit unwieldy, but I don't mind honoring him if you think it makes the name easier recognizable.

I thought if SiteArray should be renamed to something else to reflect that it's not about "sites" but about more general degrees of freedom. But DOFArray seems silly, so perhaps we can simply adapt the convention to use the short noun "site" when we mean "degree of freedom"?

We could consider combining all the finite indices of a hilbert space into one, to save storage space and to simplify indexing, but this will somewhat complicate separating them again, so we might as well wait and see.