Refactor TensorMap constructors

[lkdvos]

This PR is a refactor of the TensorMap constructors, which brings them more in line with the Array counterparts.

In particular, the default way of constructing uninitialized tensormap should now be:

TensorMap{E}(undef, codomain ← domain)
TensorMap{E}(undef, codomain, domain)
Tensor{E}(undef, space)

While they can also be constructed from actual data:

TensorMap(data, codomain ← domain)
TensorMap(data, codomain, domain)

For convenience, the following functions are also supported: rand, randn, ones, zeros

rand([T], codomain ← domain))
rand([T}, codomain, domain)
rand([T], codomain)

Finally, it is still possible to change the storagetype A, which does however require the fully specified type:

TensorMap{E,S,N1,N2,I,A,F1,F2}(undef, codomain, domain)
tensormaptype(S,N1,N2,EorA)(undef, codomain, domain) # equivalent

A similar approach is adopted for isomorphism, id, unitary and isometry:

isomorphism([TorA::Type=Float64,] codomain::TensorSpace, domain::TensorSpace) -> TensorMap
isomorphism([TorA::Type=Float64,] codomain ← domain) -> TensorMap

---

a couple questions:

• Should we try and make the default way of dealing with tensors via HomSpace, and reflect this as much as possible in the docstrings and documentation?
• There is a slight difference between constructing a tensormap with initialized blocks, where the blocks have uninitialized data, or a tensormap with uninitialized blocks. In principle, having this second option could be convenient, for example in the implementations of qr and svd, where LinearAlgebra already generates blocks.

Any feedback definitely appreciated.

[Jutho]

• Should we try and make the default way of dealing with tensors via HomSpace, and reflect this as much as possible in the docstrings and documentation?

We can, but currently that is indeed not the case, also in the implementation. E.g. similar and others call tensormaptype(...)(undef, codomain, domain). I guess that typing a comma is easier than typing a left pointing arrow with \leftarrow.

Looking at the docstring of Matrix{T}, it seems that only Matrix{T}(undef, m, n) is mentioned, even though Matrix{T}(undef, (m, n)) definitely works.

• There is a slight difference between constructing a tensormap with initialized blocks, where the blocks have uninitialized data, or a tensormap with uninitialized blocks. In principle, having this second option could be convenient, for example in the implementations of qr and svd, where LinearAlgebra already generates blocks.

Having uninitialized blocks seems like a very fragile state, that we do not want to expose to the user. Probably there are better solutions requiring less copies/allocations to fill the blocks in the case of factorisations.

[lkdvos]

Looking at the docstring of Matrix{T}, it seems that only Matrix{T}(undef, m, n) is mentioned, even though Matrix{T}(undef, (m, n)) definitely works.

Interestingly, when looking at Array{T}, the opposite is true, and only Array{T}(undef, dims) is mentioned, while the other cases also definitely work. In any case, it seems like zeros and similar mention both options so let's just keep them both as well.

---

I addressed the other comments, do you think this is ready to go?