2017年2月26日 (日)

プレイルートに曲線を導入

LongDriver のプレイルートで曲線を使用できるようにしました。曲線は2次のベジェ曲線(放物線)です。プレイルートのノードにフォーカスが当たっている時にメニュー [Each][Curve/Straight] をクリックするとフォーカスの当たっていたノードがベジェ曲線の制御点になるような曲線が描画されます。下記サンプルで4番の選手の2つ目のノードが制御点になっています(画像下側の選手マーク4番を繰り返しクリックするとノードが順次表示されます)。制御点のノードにフォーカスを当てて再度 [Each][Curve/Straight] をクリックすると通常の直線に戻ります。

曲線化とプレイ図のエンコードはすんなり出来たのですが、デコードで暴走させてしまいました。デコードの関数内に曲線用のルーチンを追加したところ、プレイ図コードのスキャン位置が合わなくなり、それが原因で暴走しました。ルーチンを追加したくらいで暴走するようなプログラムを書いていてはダメですね。

ところで、ブレイクポイントを設定してデバッグしていた時に気付いたのですが、「var foo;」のような変数宣言にはブレイクポイントを設定できないのですね。これは、最初に構文解析したら、その後の実行では変数宣言はスキャンしないということでしょうか? 今まで、このような変数宣言はループの外に記述していたのですが、実行中にスキャンしないのなら、ループの内側に記述しても効率は落ちないことになります。


    var foo;		// ループの内側↓に入れても効率は落ちない?
    for (・・・){
        var bar;
        ・・・
    }

ちなみに、最近の JavaScript では var よりも let の方が良いとか言われていますが、馴染みが薄いので、今回は let は使っていません。

なお、LongDriver を読み込む時、ブラウザによってはキャッシュのせいで古い LongDriver を実行することがあるようです。 Chrome では、再読み込みをしてもキャッシュが効いていてダメでした。新しい LongDriver を実行するには、 Chrome の再読み込みマークを右クリックして「ハード再読み込み」を実行する必要がありました。

2017年2月19日 (日)

光に質量を与えたい -2-

超伝導体内で光が質量を獲得する仕組みを知りたくて、インターネット上の資料を幾つか当たってみたのですが、未だ納得できるレベルに至っていません。取り敢えず、解った所をまとめておきます。

光の質量の獲得は秩序変数 \(\Delta\) に対する現象論(ギンツブルグ・ランダウ理論)として記述できます。秩序変数とは相転移を特徴付ける量で、考察の対象に応じて選択されます(秩序変数の超伝導相転移を参照)。この秩序変数を用いて、電磁場が無い時のラグランジアン密度は臨界点近傍で \[ \mathscr{L}=\Delta^*i\partial_t\Delta-\frac{1}{2m}\nabla\Delta^*\cdot\nabla\Delta +b|\Delta|^2+c|\Delta|^4 \tag{1} \] と表されます。ここに \(m\) はクーパー対の質量です。

(1) 式の微分を次のような共変微分に置き換えることで電磁場を導入します。 \[ \begin{eqnarray} \nabla \rightarrow \boldsymbol{D} = \nabla - i\tilde{e}\boldsymbol{A} \tag{2}\\ \partial_t \rightarrow D_t = \partial_t - i\tilde{e}\phi \tag{3} \end{eqnarray} \] すなわち、ラグランジアン密度は (4) 式になります。 \[ \begin{align} \mathscr{L} =& \Delta^*iD_t\Delta - \frac{1}{2m}\boldsymbol{D}\Delta^*\cdot\boldsymbol{D}\Delta\\ & + b|\Delta|^2 + c|\Delta|^4 + \mathscr{L}_\mathrm{em} \tag{4} \end{align} \] ここに \(\mathscr{L}_\mathrm{em}\) は電磁場のラグランジアン密度です。

\(\Delta = |\Delta|e^{i\theta}\) とおき、簡単のため \(|\Delta|\) が時間依存しないとします。そして \[ \begin{eqnarray} \tilde{\boldsymbol{A}} = \boldsymbol{A} - \frac{\nabla\theta}{\tilde{e}} \tag{5}\\ \tilde{\phi} = \phi - \frac{\partial_t\theta}{\tilde{e}} \tag{6} \end{eqnarray} \] を用いると、ラグランジアン密度は \[ \mathscr{L} = \tilde{e}|\Delta|^2\tilde{\phi} - \frac{\tilde{e}^2|\Delta|^2}{2m}\tilde{\boldsymbol{A}}^2 + \mathscr{L}_\mathrm{em} \tag{7} \] となります。このラグランジアン密度より \(\tilde{\boldsymbol{A}}\) の運動方程式は、 \(M=(\tilde{e}^2|\Delta|^2/(2m))^{1/2}\) とおいて、 \[ (\Box + M^2)\tilde{\boldsymbol{A}} = 0 \tag{8} \] となります。ただし、ローレンツゲージ \(\partial_\mu\tilde{A}^\mu = 0\) を仮定しました。 (8) 式は光子 \(\tilde{A}\) が質量 \(M\) を持っていることを表しています。

(1) 式から出発して光子が質量を獲得することが解った訳ですが、超伝導体のラグランジアン密度が (1) 式になることが理解できていません。 BCS の平均場理論によるとハミルトニアン \(H_\mathrm{mf}\) は \[ \begin{align} H_\mathrm{mf} =& -\mu c_i^\dagger c_i + c_i^\dagger t_{ij}c_j\\ & + \frac{1}{2}\langle c_i^\dagger c_j^\dagger\rangle V_{ijkl}c_k c_l + \frac{1}{2}c_i^\dagger c_j^\dagger V_{ijkl}\langle c_k c_l\rangle\\ & - \frac{1}{2}\langle c_i^\dagger c_j^\dagger\rangle V_{ijkl}\langle c_k c_l\rangle \tag{9} \end{align} \] で、 \(\Delta_{ij} = V_{ijkl}\langle c_k c_l\rangle\) が秩序変数になるのですが、これからラグランジアン密度 (1) 式の導き方が判りません。一般的にラグランジアン \(L\) とハミルトニアン \(H\) の間には \[ L = p\dot{q} - H \tag{10} \] の関係がありますが、これに (9) 式を適用するにはどうしたら良いのでしょうか。 (1) 式の質量 \(m\) は (9) 式ではどこに隠れているのでしょうか。

2016年12月 4日 (日)

光はとっくに質量を獲得していた

近接場光がきっかけで光が質量を獲得することに興味を持ち、光が質量を持つ模型という記事を見つけたことを、以前、当ブログの光に質量を与えたいで書きましたが、この「光が質量を持つ模型」よりもっと前から光は質量を獲得していたようです。その現象は超伝導体内部で発生しているそうです。超伝導体内部には光(電場も磁場も)は侵入できず、それは超伝導体内部で光が質量を獲得している表れであるということです。下記の記事に説明が有ります(PDF ファイル)。ただ、今ひとつ解った気になれませんけど。

質量の起源
対称性の自発的破れとヒッグス機構
南部理論と物性物理学

また、下記

ノート置き場

より「超伝導の基礎に関するノート」をクリックすると PDF 「超伝導の基礎に関するノート」がダウンロードされます。

超伝導体内部で光が質量を獲得する機構を、いづれ理解できたらまとめたいと思っています。

2016年11月26日 (土)

インターネットで見つけたプレイ図ソフト

アメリカンフットボールのプレイ図(プレイブック)ソフトを検索してみたところ、図のようなソフトを見つけました。アドレスは
http://footballtactics.net/playbook.html
です。

Pbsoft_alt

私のようなデザインのセンスの無い者の作った LongDriver よりも綺麗な絵になっています。

このソフトを扱っているメインページは
http://footballtactics.net/
で、サッカー用ソフトは完成しているようですが、アメリカンフットボール用は途中で止まっているのか、完成には至っていないようです。このサイトに掲載されている 「documentation」 はサッカー用なので注意が必要です。

さて、 LongDriver を、この footballtactics と比較すると次のような違いが有りました。

まず、footballtactics はデータや画像をローカルファイルに保存できるのに対して LongDriver は出来ません。方法が分からないので、画像の取得は PrtScr キーを使うという姑息な手段を使っています。

次に、 footballtactics はフィールドの向きを変えられるのに、 LongDriver は出来ません。当初、 LongDriver も変えられるようにする積りでいたのですが、気が向いたらやるということにして、未だ実装していません。

3つ目は、 footballtactics はプレイルートに曲線が使えるのに対して、 LongDriver は出来ません。これも当初は予定していたのですが LongDriver では未実装です。モチベーションが上がったら実装するかも知れません。

4つ目の違いは初期状態に関してです。 footballtactics の初期状態は選手が居ませんが、 LongDriver はデフォルトで基本的な(と思われる)フォーメーションに配置されます。それは、ゼロの状態から22人を配置するのは骨が折れるので、前もって配置しておいた方が良いだろうと考えたからです。

5つ目は、 footballtactics は単一のプレイ図しか扱えないのに対して、 LongDriver は複数のプレイ図を扱えます。これはビリヤードの配置図ソフト FlatTable からの流れとして当然の仕様です。因みに、複数のプレイ図を扱えることが LongDriver という名前の由来です。

6つ目の違いはデータの共有方法についてです。 footballtactics ではこのサイトがサーバーとなってデータを保管し、それをダウンロードすることでデータの共有を行っています。この方法だと、ブログではただの画像を表示するに止まりるため、ブログのみで footballtactics のデータを再利用(共有)することは出来ません。そのため footballtactics ではサーバーを使ってデータ共有をサポートしているのだと思われます。それに対して LongDriver では、ブログに貼り付けたデータを利用できるようになっています。

そして最後に footballtactics は Flash で出来ているのに対して LongDriver は SVG+JavaScript で出来ている点が違います。 Flash はいつまで大丈夫なのでしょうか?

追記:
6番目の項目のデータの共有は footballtactics のサッカー版では可能ですが、アメリカンフットボール版は未実装ではないかと思われます。

2016年11月21日 (月)

SVG の変換行列(CTM)

LongDriver の動作確認をしていて、選手マークをドラッグする時、マークの移動量とマウスの移動量が異なることに気付きました。試しに下に表示している LongDriver でマークをドラッグして下さい。マウスに比べてマークの移動量の小さいことが分かります。

LongDriver では、マークの移動量 deltX, deltY は、次の式で決定しています。


    deltX = (evt.clientX - pad.prevX);	// 右辺はマウスの移動量
    deltY = (evt.clientY - pad.prevY);
    ・・・
    var x = Number(target.getAttribute("x")) + deltX;
    var y = Number(target.getAttribute("y")) + deltY;
    target.setAttribute("x", x);	// target は選手マークを指す
    target.setAttribute("y", y);

このように、マウスの移動量をそのままマークの移動量としているのに、何故両者は一致しないのでしょうか?この原因は LongDriver が縮小表示され、その座標系とブラウザの座標系のスケールが異なることにあります。マウスの位置を表す evt.clientX や、それから得られる deltX 等はブラウザの座標系での値です。しかし target.setAttribute("x", x) を実行する時は LongDriver の座標系に基づいた点が選ばれるのです。そして LongDriver の座標系は縮小されているためマウスの移動量とマークの移動量が異なるのです。

SVG では、表示の大きさが変更された場合、その情報が変換行列 CTM に保存されます。 CTM は3×3行列で、新・旧座標を次の関係で繋ぎます。 \[ \begin{pmatrix} x_{prev} \\ y_{prev} \\ 1 \end{pmatrix} = \begin{pmatrix} a & c & e \\ b & d & f \\ 0 & 0 & 1 \end{pmatrix} \begin{pmatrix} x_{curr} \\ y_{curr} \\ 1 \end{pmatrix} \]

この式で左辺は旧座標系での値、右辺が新座標系での値だということに気を付けて下さい。今の場合、旧座標系とは LongDriver の初期座標系(すなわち、縮小前の座標系)のことです。この初期座標系はブラウザの座標系に一致しています。画面に表示されるのは初期座標系に換算されたものです。

上に表示している LongDriver を例に取ると CTM は \[ \rm{CTM} = \begin{pmatrix} 0.602 & 0 & 0 \\ 0 & 0.602 & 7.229 \\ 0 & 0 & 1 \end{pmatrix} \] になっています。ここで、マウスの移動量を新座標系の LongDriver に代入すると約 0.602 倍され初期座標系での移動量に換算して表示されます。逆の言い方をすると、マウスとマークの移動を一致させるには、マウスの移動量を 0.602 で割った値を選手マークの移動量とすると良いことになります。

さて、ここからは余談ですが、 CTM の成分の名前が \[ \begin{pmatrix} a & c & e \\ b & d & f \\ 0 & 0 & 1 \end{pmatrix} \] の並びになっているのは、なんとも気持ち悪いものです。何故、 \[ \begin{pmatrix} a & b & c \\ d & e & f \\ 0 & 0 & 1 \end{pmatrix} \] にしなかったのでしょうかね。

«選手のマークの番号を変更可能にした