Verbosity of Base.show for TensorMap

[AFeuerpfeil]

When running code interactively, the printing of bigger TensorMaps can be annoying because it clutters the REPL, moves previous results or sometimes even takes minutes to just print a TensorMap.

I know the printing of a TensorMap is definitely debatable. For me personally, the information like all the FusionTrees and block entries are rarely useful, if I am not debugging.

The solution I chose in my fork is to have a minimialistic Base.show that only prints the space, whilst Base.display shows all the information.

[lkdvos]

I think I definitely agree that it very often is printing information that we don't really want/need, while missing parts that we do need.

---

For starters, the summary, or compact representation doesn't include the information about any scalartype, which seems quite relevant, while sometimes not being compact at all:

"TensorMap((Rep[U₁](0 => 1, 1 => 1, 2 => 1, 3 => 1, 4 => 1) ⊗ Rep[U₁](0 => 1, 1 => 1, 2 => 1, 3 => 1, 4 => 1)) ← (Rep[U₁](0 => 1, 1 => 1, 2 => 1, 3 => 1, 4 => 1) ⊗ Rep[U₁](0 => 1, 1 => 1, 2 => 1, 3 => 1, 4 => 1)))"

For MPS tensors or environments, it becomes virtually un-parsable.

As an alternative, might I suggest, inspired by how arrays print:

10×10×10 Array{Float64, 3}:
# tensormap options:
10×10×10 TensorMap{Float64, Rep[U₁], 2, 1}:
10×10←10 TensorMap{Float64, Rep[U₁]}:
10×10←10 TensorMap{Float64, Rep[U₁], 2, 1}:
10×10'←10 TensorMap{Float64, Rep[U₁], 2, 1} # include duality information

---

Moving on to the actual printing of the data, this would then have to include the spaces as well.
I would like to put ... in the list of charge => degeneracy pairs when the number of different charges becomes quite large, in order to keep this manageable.

Then, I would like to put a limit on the number of tree => data pairs that is actually being printed. I almost never want to print 10_000 of them to the REPL :)

On top of that, I would prefer to print the blocks, rather than the fusiontree pairs. While I agree that this is less intuitive, I don't think a big list of fusiontrees really is that much better. At least, typically the number of blocks is smaller, and the clutter of printing the fusiontree itself does not get in the way. On top of that, Julia seems to do a better job at not printing out too many entries of large matrices, while this is less true for large N-dimensional arrays.

To keep both options available though, we could simply have print_trees and print_blocks and export these methods.

[AFeuerpfeil]

Hi Lukas,

Thanks for your thoughts. I really like the sizes, specifically the last one because it helps to understand the actual domain/codomain and duality structure of the current TensorMap.