search

MichielStock / Kronecker.jl

A general-purpose toolbox for efficient Kronecker-based algebra.
MIT License
86 stars 14 forks source link

Do not export unicode operators ⊗ and ⊕? #80

Open devmotion opened 3 years ago

devmotion commented 3 years ago

The unicode operators ⊗ and ⊕ are generally useful in other fields and other packages as well and therefore might be too generic to be owned and in particular be exported by Kronecker.

For instance, in KernelFunctions ⊗ will be used for creating tensor product kernels (https://github.com/JuliaGaussianProcesses/KernelFunctions.jl/pull/232) and in MeasureTheory it might be used for creating product measures (https://github.com/cscherrer/MeasureTheory.jl/issues/159). The lightweight package TensorCore contains default implementations for tensor operations such as ⊗ and can be implemented by packages with tensor operations to avoid name clashes. Originally, the code was merged in https://github.com/JuliaLang/julia/pull/35150 but later removed in https://github.com/JuliaLang/julia/pull/35744 and moved to its own package.

However, since Kronecker defines its own version of ⊗, if one uses KernelFunctions and loads the optional dependency Kronecker, warnings are displayed since both packages define the operator (or reexport in case of KernelFunctions). Unfortunately, it seems Kronecker can't implement TensorCore.:⊗ since TensorCore already contains generic definitions for AbstractArray. Maybe compatibility with TensorCore and other Julia packages could be improved by not exporting Kronecker.:⊗?

MichielStock commented 3 years ago

I understand the problem, but the very idea of Kronecker is that it exports ⊗ as a new matrix product so I would like it to export this by default. If there are conflicts with other packages that export this symbol, it would make more sense to only import the specific elements you need, no?

Still, I made this package with Kronecker kernels in mind. Would it make sense to use this as a base for tensor-based kernels?

devmotion commented 3 years ago

If there are conflicts with other packages that export this symbol, it would make more sense to only import the specific elements you need, no?

Sure, KernelFunctions does not import anything from Kronecker but calls everything explicitly in the optional methods for this reason. However, users run into this problem if they call using Kronecker with any of the packages that implement TensorCore's interface. If TensorCore would be moved backed to base Julia at some point, users could not avoid the problem even if they only use Kronecker.

Would it make sense to use this as a base for tensor-based kernels?

I am not a contributor of TensorCore but my impression is that it supposed to be a lightweight package without any dependencies apart from standard libraries (the only dependency currently is LinearAlgebra). This is not possible if it depends on Kronecker.