昨日の「テンソル積の作り方」は、線形代数の復習という意味合いがもちろんありますが、別な目的もあります。色々なものに対してテンソル積を考えたいことがあるんです。なので、一般的なテンソル積のフレームワークがあれば便利だろうと思ったわけです。
テンソル積で難しいのは、実際のテンソル積を構成するところです。しかし、事前に「テンソル積とは何であるべきか」をハッキリさせておかないと構成にかかれません。また、「テンソル積は作れそうにない、無理だ」と判断するにもテンソル積の要件が必要です。
ベクトル空間のテンソル積と同様に定義できるテンソル積の例を2つ出します。2つの例において、テンソル積として期待する条件は述べますが、その存在は示しません(よく分かってないので示せません)。これらのテンソル積は、実際に欲しいものなんですが、その背景と動機も今日は触れません。
非可換環上の双加群のテンソル積
P, Q, Rが可換とは限らない環(多元環)とします。Pが左から、Qが右から作用する両側加群を、(P, Q)-双加群と呼びます。Aが(P, Q)-双加群、Bが(Q, R)-双加群のとき、AQBと書かれるテンソル積を定義しましょう。
M2([A, B], X)は、2-複線形写像の集合とします; 基本的にはベクトル空間のときと同じですが、非可換環上の双加群なので、多少複雑になります。u:A×B→X が2-複線形写像である(つまり、u∈M2([A, B], X))とは、次のことです。以下で、P左作用、R右作用を「・」で表します。
- Xは(P, R)-双加群である。
- 任意の b∈B に対して、
- u(x + x', b) = u(x, b) + u(x', b)
- p∈P として、u(p・x, b) = p・u(x, b)
- 任意の a∈A に対して、
- u(a, y + y') = u(a, y) + u(a, y')
- r∈R として、u(a, y・r) = u(a, y)・r
- q∈Q として、u(x・q, y) = u(x, q・y) (Qによる左作用、右作用も「・」)
ベクトル空間のときと同じように圏M2[A, B]を定義します。この圏の射は、(P, R)-双加群の線形写像 f:X→Y であって、2-複線形写像u, vに対して u;f = v を満たすものです。
圏M2[A, B]の始対象 t:A×B→T があるとき、T = AQB と定義します。A×Bからの任意の2-複線形写像は、AQBからの線形写像で表現可能となります。
(P, R)-双加群XとYのあいだの線形写像の全体をL(X, Y)と書くことにすれば、次の同型が成立します。
- M2([A, B], X) L(AQB, X)
係数環P, Q, Rを省略せずに添えたほうが分かりやすいかもしれません。
- M2(P, Q, R)([A, B], X) LP,R(AQB, X)
圏のテンソル積
小さな圏C, Dに対して、それらのテンソル積CDを考えたいと思います。ここで考えるテンソル積は、アーベル圏のドリーニュ・テンソル積とは異なります。
反射的有向グラフの圏をGraphと書きます。小さい圏Cの結合を忘れ、有向グラフ構造と恒等射だけにしたものをU(C)とすると、忘却関手 U:Cat→Graph が定義できます。
忘却関手UによるCat(C, D)の像をFunc(C, D)と書くことにします。Func(C, D)はCat(C, D)と事実上同じ集合ですが、Func(C, D)⊆Graph(U(C), U(D)) です。Func(C, D)の要素は、関手的グラフ写像(functorial graph-map)と呼べます。
次に、MFunc2([C, D], X)を定義します。これは、2-複関手的グラフ写像(2-multifunctorial graph-map)の集合です。その定義は、ベクトル空間の2-複線形写像を定義したときと同じ考えに従います。
F:U(C)×U(D)→U(X) in Graph が2-複関手的グラフ写像だとは、A∈|C| を固定しての F(A, -):U(D)→U(X) と、B∈|D|を固定しての F(-, B):U(C)→U(X) がいずれも関手的グラフ写像になることです。
圏MFunc2[C, D]もベクトル空間のときと同じ要領で定義して、その圏の始対象として C×D→CD が定義されます。
以上のように、ベクトル空間のときの枠組を引き写して、圏のテンソル積の要件を定義できます。さて、この要件を満たすテンソル積を実際に構成可能でしょうか? 僕には絶望的に思えます。このままではとても無理そうです。しかし、条件を付けたり細工をすれば、テンソル積相当の圏を構成できる可能性は残っています。
「ダメだから諦めよう」とか「別な工夫をしてみよう」という判断も、要件・仕様が明確になってハジメテ出来ることなので、“テンソル積のフレームワーク”は無駄ではないと思います。