Define tensor_product

[ogauthe]

First step of the refactor detailed in ITensor/BlockSparseArrays.jl#57

OneToOne, tensor_product, dual and flip are now defined in this light weighted package.

As we may get rid of LabelledNumbers.jl, I avoided having it as a dependency.

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[mtfishman]

Thanks @ogauthe. Do you have a use case for dual, dag, and flip being in this package? I think I brought it up because I thought it may be useful for ITensor/TensorAlgebra.jl#39 but for now I went with a different design where it isn't needed. I would lean towards holding off on that for now until we have a compelling use case.

[mtfishman]

Also, do we plan to define ⊗(r1::AbstractGradedUnitRange, r2::AbstractGradedUnitRange) as fusion_product(r1, r2)? That seems like a good definition but then that makes me wonder how that would fit into the current design. If we want that, maybe a design could be:

⊗(r1::AbstractUnitRange, r2::AbstractUnitRange, r_rest::AbstractUnitRange...) = ⊗(⊗(r1, r2), r_rest...)

# Fallback definition
⊗(r1::AbstractUnitRange, r2::AbstractUnitRange) = tensor_product(r1, r2)

Then in GradedUnitRangesTensorProductsExt we could define:

TensorProducts.:⊗(r1::AbstractGradedUnitRange, r2::AbstractGradedUnitRange) = fusion_product(r1, r2)

[ogauthe]

I have no opinion on dual package, I put it here since you mentioned. I will remove it.

[mtfishman]

Relatedly, after we had discussed the idea for introducing this package, it made me wonder how FusionStyle fits in. fusedims is based on the FusionStyle of the array being fused, and will affect how the axes get fused together.

[ogauthe]

I now allow to specialize ⊗ into fusion_product.

I am unsure about FusionStyle. As we discussed in ITensor/BlockSparseArrays.jl#57, FusionStyle cannot be only about axes, it has to care about arrays. So I think it is better to keep it into TensorAlgebra, where fusedims is defined.

[mtfishman]

I am unsure about FusionStyle. As we discussed in ITensor/BlockSparseArrays.jl#57, FusionStyle cannot be only about axes, it has to care about arrays. So I think it is better to keep it into TensorAlgebra, where fusedims is defined.

I agree, ideally we wouldn't add that complexity here. The use case I have in mind is if you have a symmetric tensor (say a BlockSparseArray with graded axes) and you want to perform fusedims but not fuse the common sectors, which could be a reasonable way to do a tensor contraction where you want to want to take advantage of more sparsity (that can be helpful for contracting MPO tensors, which are often very sparse). But in that case, fusedims could call out to sector_product to fuse the axes, as opposed to ⊗ or fusion_product.

[lkdvos]

Is this obvious that we want this to be a separate type? Why not just use Base.OneTo(1)?
I wouldn't expect this to be performance critical, and this is simply more work for the compiler?

[ogauthe]

I think a dedicated OneToOne can be useful as a dummy axis for the tensor product of zero axis.

[lkdvos]

This could also be an alias:

Suggested change

	⊗() = tensor_product()
	const ⊗ = tensor_product

Then you could define methods for either, instead of both

[ogauthe]

This is not compatible with ⊗ being either tensor_product or fusion_product depending on the input.

[ogauthe]

Having Bool as a default type parameter for OneToOne leads to several issues (default blockaxes crashes and needed overwrite, other BlockArrays function crash). Base.OneTo has a dedicated line to throw when one tries to construct OneTo(true). I think we should follow the same convention and use Int as default.

[mtfishman]

Having Bool as a default type parameter for OneToOne leads to several issues (default blockaxes crashes and needed overwrite, other BlockArrays function crash). Base.OneTo has a dedicated line to throw when one tries to construct OneTo(true). I think we should follow the same convention and use Int as default.

Fine with me.

[ogauthe]

I think this is ready to merge.

[mtfishman]

I think this is ready to merge.

Looks good to me as well, I'll merge.