New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Operators for tensor sum and tensor product in Julia 0.5 #13333
Comments
This can all be done in a package on 0.4, as these operators already exist (but aren't assigned a meaning): julia> module TensorOperators
export ++, ⊗, ⊕
++(A::AbstractArray, B::AbstractArray) = vcat(A, B)
const ⊕ = ++
⊗(A::AbstractArray, B::AbstractArray) = kron(A, B)
end
TensorOperators
julia> using TensorOperators
julia> ([1,2,3] ++ [4,5,6]) ⊗ [1 2 3 4 5 6]
6x6 Array{Int64,2}:
1 2 3 4 5 6
2 4 6 8 10 12
3 6 9 12 15 18
4 8 12 16 20 24
5 10 15 20 25 30
6 12 18 24 30 36 |
Excellent, thank you @mbauman, that makes implementation easy (I hadn't looked at operators in 0.4 yet... silly me) The only thing left is this: do people feel these linear algebra primitives (⊕ and ⊗) should be included in Base, since they are pretty fundamental (and IMO useful)? |
I don't think it should be included in Base. Depending on the context these operators could do different things, for example Voigt tensor. |
Sure, if you have a tensor stored in some different storage format, you would have to implement the operators themselves for your type - if you wanted to use them. Same would go for hcat and vcat, though, right? The output shouldn't be ambiguous given the input types (the tensor sum of two symmetric matrices is still a symmetric matrix, for instance, but you can't just concatenate the Voigt vector representations without further information like a block-diagonal representation or padding a larger matrix with zeros. But Julia would already know they are some For vectors, I would think of ⊕ as a convenient way of accessing |
I think the trend is to reduce the size of Base by moving code to separate modules, not the other way. The plan is to have a set of modules installed/loaded by default, among which e.g. sparse matrices, linear algebra, etc. So if you create a Tensors.jl package and it becomes popular, it will be easy to ship it with Julia by default later. Being in Base doesn't give you any special privilege other than that. |
See also #3250 and https://github.com/Jutho/TensorOperations.jl ... but that is a little different, focused on contractions. |
In general, for defining these in Base I'm worried that the meaning of ⊕ and ⊗ is not universally agreed upon in different mathematical contexts. (In contrast, there is no widespread meaning for e.g. Trefethen's Numerical Linear Algebra book uses them to denote floating-point (rounded) addition and multiplication (as opposed to exact addition and multiplication). Even in the tensor context, whereas in some contexts you want |
Note that |
|
They're also used in groups and rings. I don't think julia needs to claim them. |
Are groups and rings represented in Julia with different types (in which case, where is the problem?), or all they all just |
|
I agree that this should not be in Base; specific implementations belong in a package (e.g. I also explored this last year also in my mostly unfinished TensorToolbox.jl ). I don't see that there is a unique generalisation to tensors anyway, so this could at most be some shorthand notation for |
Closing as the consensus seems clearly against. |
Thank you all very much for you comments. I would have closed this some time ago but I've been travelling. (If I had of known the symbols were so ambiguous, I wouldn't have opened it in the first place...) |
Following the discussion on Arrays in Julia 0.5 #13157 , I want to suggest including new operators for the tensor sum (or direct sum) operation and for the tensor product (outer product).
The tensor sum (direct sum) is a way of combining both vector spaces as well as tensors (vectors, matrices or higher order arrays) of the same order. The tensor sum of two vector spaces V1 ⊕ V2 simply concatenates their two bases. Similarly, the tensor sum of two vectors v1 ⊕ v2 is their concatenation,
vcat(v1,v2)
. For higher order tensors (higher dimensional arrays), all the vector spaces associated with each dimension are concatenated, and the elements of the arrays are filled in their original positions, resulting in a sparse (block diagonal) tensor. For example, the tensor sum of two matrices A ⊕ B is[A 0; 0 B]
. Care would need to be taken for row vectors stored as 1-by-n arrays, but hopefully this will be resolved separately in Julia 0.5. For tensor sum, I suggest we use the usual symbol⊕
(use\oplus
in the REPL), but we could also consider++
or other operations (please suggest). The tensor sum operator might be useful in other concatenation contexts, such as string concatenation (since ⊕ is non-commutative and is basically the correct monoid for concatenating vectors of characters), but this is not the main point at this stage.The tensor product (outer product) on vector spaces V1 ⊗ V2 creates a new basis with elements that are all possible outer products of the basis elements of V1 and of V2, and so the dimension of the resulting vector space becomes the product of the two individual dimensions. Julia already implements
kron()
which is the same idea, but restricted to only vectors and matrices. We could generalizekron
and use⊗
(\otimes
in the REPL) or**
(or something else) to implement this. Tensor products might be similar to other operations in other contexts - for example the outer join in relational algebra behaves similarly, so we could implement that forDataFrame
s.Tensors and multilinear algebra are described by bi-monoidal categories (with the two monoids ⊗ and ⊕) so these to operations will make that a little simpler to write and reason about. Besides, these operators may have use in other fields where concatenation or outer products make sense. What is the policy on adding new operators to Julia? Is this frowned upon? Can we use unicode symbols, or must we continue with multiple ASCII symbols (which I find a bit ugly...)? Does anyone else think this is useful? If the community wants this feature, I could work on it and generate a PR (though the parser confuses me...)
The text was updated successfully, but these errors were encountered: