上付き・下付き添字をマジに考えたら頭痛がした

先日の記事「古典的微分幾何・ベクトル解析のモダン化： ダイレクトインデックス記法」で、上付き・下付き添字の説明をしたのですが、説明の対象である上付き・下付き添字以外に、上付き・下付き添字の記法を大量に使っている事実に気が付きました。随分とひどいオーバーロード〈多義的使用〉だわ。「過度のオーバーロードはやめよう」と主張している僕としては、ちょっと愕然としました。

僕自身が上付き・下付き添字をどんな目的で使っているかを解説することにより、反省の材料にしたいと思います。また、「古典的微分幾何・ベクトル解析のモダン化： ダイレクトインデックス記法」の分かりにくい記法への補足説明でもあります。

「古典的微分幾何・ベクトル解析のモダン化： ダイレクトインデックス記法」と強く関係している節（第5節です）を読み流してもらえれば、上付き・下付き添字記法がどのように使用されているかの調査報告（ただし、サンプル数は1）としても読めるでしょう。

内容：

上付き・下付き添字の使用状況

gがニ変数〈ニ引数〉の関数〈写像〉のとき、g(a, b)を短く書くために単なる併置〈juxtaposition〉を使います。

• g(a, b) = ab

と書くわけです。掛け算が併置で書かれることはお馴染みですね。併置以外で短く書く記法というと、aとbの配置を斜め上下にすることにして：

1. g(a, b) = a^b
2. g(a, b) = a_b
3. g(a, b) = ^ba
4. g(a, b) = _ba

となります。左上下はあまり使わないので*1、よく使うのは a^b と a_b です。これが上付き添字〈superscript | スーパースクリプト〉と下付き添字〈subscript | サブスクリプト〉です。添字をインデックス〈index〉ともいいます。

一変数関数fに対しても、f(a) を上付き・下付き添字で表すことがあります。

1. f(a) = f^a
2. f(a) = f_a
3. f(a) = a^f
4. f(a) = a_f

f(a) は、fのaによる評価〈evaluation〉または（同じことだが）aへのfの適用〈application〉なので、f(a) = eval(f, a) = app(a, f) とすれば：

1. eval(f, a) = f^a
2. eval(f, a) = f_a
3. app(a, f) = a^f
4. app(a, f) = a_f

と書けるので、ニ変数関数の添字記法だと解釈できます。

上付き添字の形で、たいていの人が思い出すのはニ変数の指数関数でしょう。

• exp(a, b) = a^b

この用法が多いので、上付き添字を見ると指数だと解釈してしまう人が多いみたいです。上付き添字と指数の結びつきは一旦チャラにして、「この上付き添字はどんな意味だろう？」と毎回考えるようにしてください。

マヤカシのRⁿ

ここから先は、僕の記事「古典的微分幾何・ベクトル解析のモダン化： ダイレクトインデックス記法」に出現する上付き・下付き添字を、ほぼ出現順に解説していきます。

最初に出た添字表現は「Rⁿ」です。ユークリッド空間と呼ばれる集合です。とりあえずこれは、数の指数と同じく“n個の累乗”という意味です。

• Rⁿ = R× ... ×R （n個）

こういう説明や定義をするたびに、僕は少し後ろめたくなります。これはマヤカシです。

2つの集合A, Bに対して、その指数〈ベキ〉を、

• B^A = (AからBへのすべての写像からなる集合) = Map(A, B)

とします。B^A = Map(A, B) は標準的記法として認めましょう。この指数（上付き添字）記法が腑に落ちない方は次の記事をどうぞ。腑に落ちてる方は参照不要。

• なんでソコに、足し算、掛け算、累乗の記号を使うのですか？

[0] = {}, [1] = [1], [2] = {1, 2}, ... などと定義します。一般的には、

• [n] := {k∈N | 1 ≦ k ≦ n}

通常Rⁿと書かれているものは、R^[n] = Map([n], R) = Map({1, ..., n}, R) と解釈したほうがいいです。何故かと言うと、もし、R³ := R×R×R としてしまうと、x∈R³ の下付き添字表示が x = (x₁, x₂, x₃) とは書けずに、x = (x₁, x₂), x₁ = ((x₁)₁, (x₁)₂) と書くハメになるからです。

'×'が二項直積の演算子記号として、R×R = R^[2] は言えます*2が、R×R×R = (R×R)×R = R^[3] は言えないのです。R^[3]の要素 t = (a, b, c) （t(1) = a, t(2), t(3) = c）に対応する (R×R)×R の要素は、{1:{1:a, 2:b}, 2:c} とでも書くべきものです。 R×(R×R) の要素なら {1:a, 2:{1:b, 2:c}} です。もとの3-タプルは、(a, b, c) = {1:a, 2:b, 3:c} です。

{1:{1:a, 2:b}, 2:c}, {1:a, 2:{1:b, 2:c}}, {1:a, 2:b, 3:c} はイコールではなく、次の同型があるだけです。

• (R×R)×R R×(R×R) R^[3]

これは、つまらない話でも簡単な話でもなく、難しくて重用な話題です。直接の発展としては、モノイド圏に関するマックレーンの一貫性定理〈Mac Lane's coherence theorem for monoidal categories〉があります。

「二項直積演算が厳密には結合的ではない」という困難を避けるためには、R³ = (R×R)×R ではなくて、R³ = R^[3] = Map({1, 2, 3}, R) と解釈したほうがいいでしょう。

引数としての添字

「古典的微分幾何・ベクトル解析のモダン化： ダイレクトインデックス記法」で二番目に登場する添字記法は、「(ξ_i | i = 1, ..., n)」です。これは、ξ∈Rⁿ を成分表示したものです。前節で述べたように、Rⁿ = R^[n] と考えると ξ∈Map([n], R) です。ξは関数ですから、型付きラムダ記法で書けば：

• ξ = λi∈[n].ξ(i)

ξ(i) を ξ_i と書けば、λi∈[n].ξ_i 、これを (ξ_i | i∈[n]) のようにも書くのです。一般的に、関数 λi∈I.f(i) の別表記として (f_i | i∈I) とか (f_i)_i∈I とか書かれます。これは単に関数〈写像〉の別表記に過ぎないのですが、こう書くとインデックス族〈indexed family〉と呼ばれたりします。「インデックス族」あるいは単に「族」は、「関数」と同義であり、使い分けは気分だけです*3。

「(ξ_i | i = 1, ..., n)」における下付き添字の用法は、関数への引数渡し〈評価〉です。次のように書いてもまったく同じ意味です。違いは気分だけ。

1. ξ(i)
2. ξⁱ
3. ξ[i]
4. eval(ξ, i)
5. app(i, ξ)

作用素としての添字

次に「f^~」という上付き添字が登場します。この例では、上付きの'~'が作用素〈operator | オペレータ〉で、fがその引数〈オペランド | operand | 被作用項 | 被演算項〉です。「作用素」という言葉も、結局は関数・写像と同義語ですが、気分としては、“集合や関数を引数にとる関数”を作用素とか汎関数〈functional〉とか呼ぶ傾向があります。operatorの訳語が「作用素」または「演算子」なので、演算子でも作用素と同じニュアンスがあります。

上付き'~'が表す作用素をextとすれば、次の表現は同じ意味です。

• f^~
• ext(f)
• eval(ext, f)
• app(f, ext)

extは、実はモナドのクライスリ拡張〈Kleisli extension〉オペレータです。モナドに関する解説は、興味があれば、次の記事からの参照をたどればいいと思います。

• TypeScriptでモナド 改善編

f^~ において、f∈Map(A, X) だった（元の記事参照）ので、(-)^~ = ext は次のようなオペレータ〈作用素 | 演算子〉です。

• ext:Map(A, X)→Lin(R^A, X)

ここで、Lin(-, -) は線形写像全体からなる集合を表します*4。extは、ベクトル空間Xとその基底Aに依存して決まるので、正確には ext_A,X のように書きます。あっ、またしても添字がぁー …

ext_A,X のように、集合や構造に依存して写像が決まることは多いのです*5。これも、(集合や写像)|→写像 という写像なので、ext(A, X) のように書いてもかまいません。しかし、ext(A, X) 自体がオペレータなので、f∈Map(A, X) を渡すと ext(A, X)(f) が出力されて、それがまた線形写像なので、ext(A, X)(f)(ξ)∈X となります。ここで最後の引数になっている ξ∈R^A も写像（A→R）という状況です。引数渡しをすべて丸括弧で書くと区別が付きにくいので、添字にしたり角括弧〈ブラケット〉にしたりで、多少は見やすくするわけです。プログラミング言語だと、山形括弧もよく使います、ext<A, X> のように。

オペレータを表す添字や、集合や構造が引数になる場合の添字の例として、他に次があります（元の記事での出現順）。

• incl_A,X:A→X （A⊆X の包含写像）
• A^→ （上付き→は、基底からフレームを作るオペレータ）
• (A^→)^-1 （上付き-1は、逆写像を作るオペレータ）
• A^← （上付き←は、基底から逆フレームを作るオペレータ）
• id_X （Xの恒等写像）

問題の“あの添字記法”

僕が「古典的微分幾何・ベクトル解析のモダン化： ダイレクトインデックス記法」で導入・解説したかった添字記法は、ベクトル空間Xとその基底Aに対して、g_X,A:X×A→R という写像です。この写像の意味から、gではなくてdirectCoeffという長い名前を使いましょう。“ダイレクトな係数”〈direct coefficient〉の短縮です。

directCoeffは、ベクトル空間Xとその基底Aに依存して決まる写像です。directCoeff(X, A)でもいいですが、前節で述べた理由から、directCoeff_X,Aとします。
directCoeff_X,A:X×A→R なので、x∈X と a∈A を渡すと directCoeff_X,A(x, a)∈R が定まります。この値を自然言語で説明すると*6：

• directCoeff_X,A(x, a) := (Xのベクトルxを、基底Aで展開したときの、aに対する係数)

ベクトルxの展開（線形結合による表現）は次のようになります。

いかにも長ったらしいので、directCoeff_X,A(x, a) を coeff(x, a) に省略・短縮すれば：

これでも頻繁に書くには辛いので、二変数関数への引数渡し coeff(x, a) を上付き添字記法にしようというわけです。

• coeff(x, a) = x^a

こうすると、固定したaに対して

• λx∈X.coeff(x, a) = λx∈X.x^a

λx∈X.x^a のラムダ変数を無名化（ハイフン化）して λx∈X.x^a = (-)^a 、したがって、

• (-)^a = coeff(-, a)

いかなる（有限次元）ベクトル空間Xと基底Aに対しても同じ記法が使えます。標準双対ベクトル空間X^*と双対基底A^#に対しても、次のことは言えます。

• (-)^w = directCoeff_X^*,A^#(-, w)

しかし、w = (-)^a のときに、

• (-)_a = directCoeff_X^*,A^#(-, (-)^a)

という下付き記法を導入します。X^*上での下付き添字と上付き添字の関係は (-)_a = (-)^(-)a です。

今までの説明のなかに、X^*とA^#という上付き添字が出てますが、これは、集合や構造に作用するオペレータとしての添字です。上付き星印は、ベクトル空間の標準双対空間を作るオペレータ、上付きシャープ記号は、ベクトル空間の基底に対して双対基底（標準双対空間の基底）を作るオペレータです。

今になって思っていることは； (-)^aという記法は分かりにくかったなー、です。基底Aと双対基底A^#のあいだには、集合としての1：1対応（全単射）があるので、その全単射も上付きシャープ記号でオーバーロード（同じ名前で違うものを表す）して、(-)^aの代わりに a^# を使えば良かったかな、と。上付きシャープを、ゲルファント変換を表す上付きハット（サーカムフレックス記号）と一緒に使うと、展開公式が次の形になります。

[tex: x \,=\, \sum_{a \in A}a ]
[tex: v \,=\, \sum_{a \in A}a^{\sharp} ]

<-|-> は標準ペアリング（<-|-> は評価 eval(-, -) と同じ）だとして、x^a := <a^#|x> , v_a := <a^{^}|v> がダイレクトインデックス方式による上付き・下付き添字の定義になります。これって、スッキリしてんでしょ、まだ改善の余地があるかもしれないけど。構文・記法の設計は難しいけど楽しいなー。

カリー化した関数を表す添字

gは2変数関数 g:X×Y→Z だとします。gの第一引数をaに固定して Y→Z という関数だとみなしたものを g_a と書きます。これも下付き添字ですな。

• g_a(y) = g(a, y)

無名ラムダ変数（ハイフン）を使って書けば、g_a(-) = g(a, -) ですが、ちゃんとしたラムダ記法で書くと：

• g_a = g_a(-) = λy∈Y.g(a, y)

aも動かしていいので、

• g_(-) = λa∈X.g_a(-) = λa∈X.λy∈Y.g(a, y)

ラムダ変数は束縛変数なので、リネームしてもいいですから λa∈X.λy∈Y.g(a, y) = λx∈X.λy∈Y.g(a, y) 、こう書くと分かってくると思いますが、g_(-) はgのカリー化だったのです。

もとの関数が λ(x, y)∈X×Y.g(x, y) という二変数だったのを、λx∈X.λy∈Y.g(a, y) という“一変数関数を値とする一変数関数”にしています。これがカリー化です。

• g_x(y) = (λx∈X.λy∈Y.g(a, y))(x)(y)

なので、下付き添字は、カリー化した後の変数〈引数〉として使われます。

g:X×Y→Z のカリー化を g^∩:X→Z^Y と書きます。これまた上付き添字を使ってます。カリー化オペレータを表す上付き添字ですね。この書き方の由来（絵）は、「非対称閉圏のカリー化：記号法を工夫すれば、右と左の混乱も解消」を参照してください。

• g_(-) = g^∩
• g_x = (g^∩)(x)
• g_x(y) = (g^∩)(x)(y)

g:X×Y→Z に対して、^∩g:Y→Z^X というカリー化もできます。ラムダ記法で書くなら：

• ^∩g := λy∈Y.λx∈X.g(x, y)

^∩g を添字で表現するときは、上付きにします。

• g^(-) = ^∩g
• g^y = (^∩g)(y)
• g^y(x) = (^∩g)(y)(x)

「古典的微分幾何・ベクトル解析のモダン化： ダイレクトインデックス記法」のなかで、クロネッカーのデルタ δ:S×S→R に対して次の書き方を許しました。

1. δ(s, t)
2. δ_s(t)
3. δ^t(s)
4. δ_s^t

最初の3つは、δ, δ^∩, ^∩δ に引数を順次（添字が先、丸括弧が後で）渡した形です。最後のは δ_s^t = δ(s, t) とみなしてかまいません。

カリー化が登場する別なケースを見てみましょう。eval_S,T:T^S×S→T, app_S,T:S×T^S→T で、evalとappは引数順序が逆転するだけとします。

• eval(m, s) = app(s, m) = m(s)

eval_A,R:R^A×A→R を考えると、eval(ξ, a) = ξ(a) です。このevalを左側で（もとの第二引数が変数になる形で）カリー化すると：

• (^∩eval(a))(ξ) = eval^a(ξ) = ξ(a)

つまり、evalの左カリー化は射影に他なりません。

• eval^a(ξ) = π^a(ξ) = ξ(a)

eval^aの上付きaは左カリー化に起因して、π^aの上付きaは異なる射影を識別するラベルです。もとの定義も上付きの使用法も違いますが、eval^a = π^a です。

ベクトル空間Xの標準双対ベクトル空間X^*は、関数の空間なのでevalを考えことができます。eval_X,R:X^*×X→R で、

• eval(v, x) = v(x) = <v|x>

このevalを左カリー化すると：

• (^∩eval(x))(v) = eval^x(v) = v(x) = x^{^}(x)

eval^xはxのゲルファント変換x^{^}です。^∩eval自体は、^∩eval = Ж_X : X→X^* を与えます。Ж_Xは「双対ベクトル空間、もう少し知っておいたほうがイイカモ // シャーとジェー」で定義しています。

おわりに

上付き・下付き添字は、併置の次に簡単で便利な記法です。長い関数名などを使わないで上付き・下付き添字で略記したい、とは誰もが思うでしょう。その結果、いろいろな関数が上付き・下付き添字記法で略記されることになります。出現した上付き・下付き添字が何を意味するかは、注意深く判断する必要があります。

使える文字・記号・記法はたいして多くないので、多義的使用／文脈依存は仕方ないのですが、そのなかでも上付き・下付き添字は大人気の記法ですから、超多義的使用／超文脈依存なのです。ちょっと頭痛がします。

*1:「カン拡張における上下左右： 入門の前に整理すべきこと」では、左上、左下、右上、右下に配置した添字をすべて使っています。互いに関連した4種類の二項操作を表現するためです。

*2:R×Rの定義として、R^[2]を採用してよい、ということです。

*3:インデックス族とかパラメータ族というと、値の領域が確定した集合ではないような印象はあります。集合とは限らない類〈class〉に値をとる場合が族の雰囲気。このテの話を、印象・雰囲気で議論してもラチがあかないので、やめときます。

*4:厳密には、Map(A, X)のXは、忘却関手をUとして U(X) です。集合圏とベクトル空間の圏のあいだの随伴関手対があるのです。

*5:自然変換や圏論的オペレータです。

*6:directCoeffの定義を形式言語でしようとすると、述語論理の論理式以外にヒルベルトのイプシロン記号が必要になります。