Constructing tensor product generalization?

[hammerfunctor]

As title demonstrates, I want some tool to create an external tensor product space under two non-interacting Clifford algebra (just like to create a tensor product space under two basic linear space). Addition is like addition in tensor product space, and multiplication is inherited from former Clifford algebra. I look around but find nothing.
I wonder is this already implemented? Or how can I create it myself ?(I have tried it a bit, but external tensor basis seem not that easy... Where can I find some references.)
Thank you in advance.

[chakravala]

As it so happens, I am working on another tensor product implementation (already before you raised this issue):

julia> using Grassmann#master

julia> Chain(1,2)⊗Chain(3,4)
(1v₁ + 2v₂)⊗(3v₁ + 4v₂)

julia> ans⋅Chain(5,6)
39v₁ + 78v₂

Is this the sort of thing you are asking about? Please clarify what you are trying to accomplish.

[hammerfunctor]

For instance, Cl(e1, e2, ...)⊗Cl(o1, o2, ...) should mean tensor product of Clifford algebra (not tensor product in the definition of Clifford algebra), i.e., [ei, oj] == 0, {ei, ej} == ±2δᵢⱼ, {oi, oj} == ±2δᵢⱼ, where square brackets mean commutator, curl brackets mean anti-commutator and plus/minus depend on detailed situations.
So the basis of product space is simply {eᵢ₁...eᵢᵥ⊗oᵢ₁...oᵢⱼ}. Since generators of two Clifford are commutative, "⊗" can be ignored without any ambiguity.

[TsurHerman]

I think you would get what you want easily if it was possible to have a Cl(o1, o2, ...) as the underlying field(ring?) for Cl(e1, e2, ...)
@chakravala programatically it is a very small change to allow that.

@chakravala I started writing my own geometric algebra package out of curiosity, and I am very impressed with the depth and
performance of Grassmann , it gives me something to compete with so as not to settle on half measures in my design 👍

[chakravala]

This feature is already implemented in Grassmann you simply take the DirectSum of the two:

julia> Λ(ℝ3)⊕Λ(ℝ3)
DirectSum.Basis{⟨××××××⟩,64}(v, v₁, v₂, v₃, v₄, v₅, v₆, v₁₂, v₁₃, v₁₄, v₁₅, v₁₆, v₂₃, v₂₄, v₂₅, v₂₆, v₃₄, v₃₅, v₃₆, v₄₅, v₄₆, v₅₆, v₁₂₃, v₁₂₄, v₁₂₅, v₁₂₆, v₁₃₄, v₁₃₅, v₁₃₆, v₁₄₅, v₁₄₆, v₁₅₆, v₂₃₄, v₂₃₅, v₂₃₆, v₂₄₅, v₂₄₆, v₂₅₆, v₃₄₅, v₃₄₆, v₃₅₆, v₄₅₆, v₁₂₃₄, v₁₂₃₅, v₁₂₃₆, v₁₂₄₅, v₁₂₄₆, v₁₂₅₆, v₁₃₄₅, v₁₃₄₆, v₁₃₅₆, v₁₄₅₆, v₂₃₄₅, v₂₃₄₆, v₂₃₅₆, v₂₄₅₆, v₃₄₅₆, v₁₂₃₄₅, v₁₂₃₄₆, v₁₂₃₅₆, v₁₂₄₅₆, v₁₃₄₅₆, v₂₃₄₅₆, v₁₂₃₄₅₆)

julia> Λ(ℝ^3)⊕Λ((ℝ^3)')
DirectSum.Basis{⟨+++---⟩*,64}(v, v₁, v₂, v₃, w¹, w², w³, v₁₂, v₁₃, v₁w¹, v₁w², v₁w³, v₂₃, v₂w¹, v₂w², v₂w³, v₃w¹, v₃w², v₃w³, w¹², w¹³, w²³, v₁₂₃, v₁₂w¹, v₁₂w², v₁₂w³, v₁₃w¹, v₁₃w², v₁₃w³, v₁w¹², v₁w¹³, v₁w²³, v₂₃w¹, v₂₃w², v₂₃w³, v₂w¹², v₂w¹³, v₂w²³, v₃w¹², v₃w¹³, v₃w²³, w¹²³, v₁₂₃w¹, v₁₂₃w², v₁₂₃w³, v₁₂w¹², v₁₂w¹³, v₁₂w²³, v₁₃w¹², v₁₃w¹³, v₁₃w²³, v₁w¹²³, v₂₃w¹², v₂₃w¹³, v₂₃w²³, v₂w¹²³, v₃w¹²³, v₁₂₃w¹², v₁₂₃w¹³, v₁₂₃w²³, v₁₂w¹²³, v₁₃w¹²³, v₂₃w¹²³, v₁₂₃w¹²³)

The multiple basis names v and w are only used when the second algebra is the dual of the first, in the sense of David Hestenes, otherwise, all the basis elements are just renumbered. The feature could be extended of course, but why would I do work for people who are gonna re-implement my repo separately anyway?

Since generators of two Clifford are commutative, "⊗" can be ignored without any ambiguity.

Disagree on this point, if you have take two Clifford algebras and take their direct sum, you end up with one giant Clifford algebra. What applications do your "commutative" Clifford algebras have? Why should i spend my time pleasing you on this feature for free?

@TsurHerman yes I'm aware that now suddenly everyone and their grandmother want to copy me and my designs even though people spent years telling me I'm crazy, now in the last month 3 people have created a copy cat repository based on mine

@TsurHerman i recommend you adhere to the AGPL software license of my repository

I am very impressed with the depth and performance of Grassmann , it gives me something to compete with so as not to settle on half measures in my design +1

It disappoints me a quite bit that people want to copy my designs instead of contributing

[TsurHerman]

@chakravala I think you misunderstood, I am not copying your design or package, simply implementing geometric algebra on my own terms and for my own needs, to get a better understanding.

I benchmarked my results compared to Grassmann.jl (on the algebra that interests me e.g PGA3D) and was impressed at how everything was type stable and optimised. It sent me into rethinking my design and seeing the close relationship between the algebra itself and the meta of code generation.

I will be happy to contribute once I have gained more ground and once I have something meaningful to contribute, in the meantime please take it as a complement.

[hammerfunctor]

@chakravala Dear chakravala, I will say sorry if it bothered you.
But "commutative" is a natural requirement by tensor product of the algebra, just like to do tensor product for other associative algebras.

Let U={u1, ..., un}, V={v1, ..., vn}, what I referred to is not Cl(U⊕V), but directly Cl(U)⊠Cl(V), although dimensions of both of them are (2^n)^2.

For the first case, u1 v1 = -v1 u1 because of the structure of Clifford algebra generated by U⊕V. While for the second case, u1 v1 means u1⊠v1 essentially (I use "boxtimes" to avoid possible ambiguity), and you can strictly keep "⊠" and the order of u and v if you want. Multiplications are defined by (u1⊠v1)(u2⊠v2) -> (u1 u2)⊠(v1 v2). Structure under this kind of "tensor algebra" looks like we just "multiply" two kinds of basis (omit ⊠) and force them to commutate.

If it is possible I will also contribute to this repo.

[chakravala]

@hammerfunctor another way of representing this object might be with nested geometric algebra, which is more easily possible to do without much additional effort, otherwise the change you are proposing is very significant, and would require to basically redesign the entire system of packages to accommodate what seems like a small request

I will need to think about this some more, because I have a lot of other things on my mind currently, and redesigning the core features to expand all the products into this format would be a rather significant rewrite, but I believe that using recursive or nested structures for that kind of algebra would be easier and less work to implement for this

@TsurHerman yes I know your intentions are good but hope you understand how I feel about it, as a person who has been basically outcast and banned from academia, I put in thousands of hours of work into this for free, and it makes me feel bad when people take from my work for their own benefit, while I struggle with being banned from industry/academia

there is at least one person who is now re-implementing my work who wants to actively exclude me and ostracize from their work, so now I am seeing a bunch of people hopping in on this trend, and I am not sure what their intentions are to me personally, so please understand I am skeptical of people's intentions recently