Orz日記 by Akio Morita

_ [LHC]β測定ソフトウェアのテスト

SPSを使った総合試験が今週月曜日と木曜日に行われたが、 BPMの調整がうまくなかなかビームが測れない(月曜日)とか 加速器側の不調でビームがなかなか来ない(木曜日)などの 障害によって、Turn-By-Tuen BPMから位相情報を引き出す あたりまでしかテスト出来なかった。

またしても、COD測定ベースの私のコードは出番無し Orz

_ [LHC]Transport LineでのTransfer Matrixの再構築

仮のTransfer MatrixとBetatron振動の測定値x(s)からx'(s)を推定し、 x(s),x'(s)から Transfer Matrixの推定値を改良するというイテレータを 組んでみたがどうもうまくいかない。 状況としては、

• イテレータ自体は不動点を持つ
• モデルの Transfer Matrixからスタートしても別の不動点(明らかに物理的では無い)へ収束する
• Transfer Matrixのモデルからのノルムの動きは、x'(s)を推定する差分の組み方に依存している

な感じで、数値的不安定性が有るようにも見えます。 特に、モデルのTransfer Matrixからスタートして明後日の方向へ走って行く ようでは使い物になりそうに無いので、Transfer Matrixと下流側の 軌道位置情報から上流の軌道を推定し、推定軌道と測定値の残差２乗和を 方向集合法で最小化するコードをテスト中。

現時点で分かっていることは、

• モデルの Transfer Matrixから計算した残差２乗和は小さい
• モデルの Transfer Matrixを出発値にした際の振る舞いから、近傍は極小点になっている用に見える
• Powellの方向集合法だと極めて収束が遅い
• 共役勾配法がうまく動かない(数値微分が怪しい)

現在、ドリフトスペースで近似した Transfer Matrixを出発値にして グローバルな収束性が有るかどうかをテスト中だが... 仮に収束するとしても遅すぎて実用に耐えないと思われる Orz

_ [LHC]CGPRがうまく動かない件

Powellの方向集合法では時間ばかりかかってちっとも収束しないので CGPRがうまく動かない原因を調査開始...

CGPRで使う数値微分を疑っていたのだが、数値微分そのものは 問題なく計算出来ていた。ただし、微分で求めた勾配ベクトルの ノルムが非常に大きい(1e22とか...)ので、勾配ベクトルに そった直線上で最小化(Brentのアルゴリズム)を行う際に、 評価関数の評価が上手くいかない模様。2x2の Transfer Matrixを 3パラメータで表現しているのだが、パラメータ毎の固有スケールが 大きく異なるのが原因のようだ。

行列式が 1であるという条件を外して 4パラメータ表現に 変えると、CGPRのアルゴリズム自体は動く模様。 ただし、このままだと行列の行列式が保存しないのでもう一工夫必要。

_ [SAD]Ticket-16の件

これって、組み込み関数シンボルを特殊扱いしているせいでは無いだろうか...

組み込み関数を直接書かなければ、

 In[1]:= f = Sin
Out[1]:= Sin
 In[2]:= Hold[f[1]]
Out[2]:= Hold[f[1]]
 In[3]:= ReleaseHold[Out[2]]
Out[3]:= .841470984807896

になるようです

おそらく、itfunalocで定義した組み込み関数は SADScript側から 再定義出来ないので、Hold[]前とReleaseHold[]後の評価結果が 一致することを暗に仮定して正格評価を行っていると思われる。

さらに、Hold[]にツッコミを入れると、Hold[]が実際に保存するのは 評価前の構文木なわけで、組み込み関数はシンボルその物ではなく 関数番号が構文木に組み込まれるので、Hold[]した結果を ReleaseHold[]する前に itfunalocで定義済みの関数シンボルを オーバーライドするとReleaseHold[]時に評価される関数は、 オーバーライド後ではなくオーバーライド前の関数になるという 一見不可思議な現象が発生します。 さらに、Hold[]を ToStringでシリアル化してToExpressionで式に 変換した場合はオーバーライド後の関数に化けるはず。

_ [SAD]Ticket-16の件(その2)

昨日のツッコミで、マニュアルの書き換えと言う 提案も出ているが、議論すべき点はHold[]関数の動作をどう定義するかで あって、現状の実装やマニュアル上の記述では無いと思う。

現状の実装が仕様通りならばマニュアルを改訂すべきだし、 そうでないなら実装を修正しなければならない。 で、問題は「仕様書はどこ？」という疑問に行き着く訳で...

処理系としては、関数の意味論以前に字句・構文解析自体にもいろいろ 問題があるのも頭の痛いところ(そもそも、文法が yaccで記述可能な LALR(1)な CFGに入るかどうか自体が怪しい)

_ [SAD]Ticket-16の件(その3)

実装を修正すべきとのツッコミがあるが、誰がやるの？

多分、evalエンジン自体の修正がいると思うけど、きちんとした資料無しに 修正できるレベルでは無いと思うのだが...

_ [雑記]今日は風が心地よい

最近、天気が良く日差しと風が強い日が続いていたのだが、 今日は少し曇りぎみで風もさして強くなく、窓を開けておくと 心地よい風が流れ込んでくる

_ [LHC]軌道応答からのTransfer Matrixの再構築

色々試してみたが、安定性を考えると愚直なアルゴリズムが良いようで、 Transfer Matrixの候補を使って軌道応答(x_i)の一部の情報から (x_n, x'_n)ペアを推定してこれを転送することで軌道応答の推定値を 組立て、軌道の誤差２乗和で評価関数を組み立てて共役勾配法で 誤差を最小化するコードを組んでみたのだが...

どうやら、解にエイリアスが発生する(近傍に別の極小点が存在する)模様です。

まず、モデルの Transfer Matrixを出発値にして共役勾配法を走らせるて 収束した値を基準にして、これへガウスノイズを加えた別の出発値から 共役勾配法を走らせ結果との距離を測ると...別の極小に落ちてる用に見える。

最小化している誤差２乗和の大きさは両者ともに同じ程度 $3\times10^{-7}$ で、各点毎の軌道応答と推定値の残差は $1\times10^{-7}$オーダーで 二つの結果の差異は $3\times10^{-9}$に入っている。

位相空間の推定に使うサンプルの位置を変えても、収束後の値では評価値は 変わらない(収束前は当然、矛盾を含むので影響がある)ので、 そういう改良では解決出来そうに無い。

取り合えず、

1. 入力情報(軌道の種類)が不足している
2. 評価関数が真の解近傍に極小点を多数持っている

のどちらに本質的な問題が有るかを調べるために入力情報を増やした テストを実施してみる。

未知変数と方程式の数を大雑把に数えた限りは決定出来そうなのだが...

_ [SAD]V1.0.10.2.7a6

amorita branchへの MFC終了〜

MAIN trunk側のコードは Packages/HelpMessages.nと src/MAIN.fの 表示は 1.0.10.2.7a5/1.0.10.2.7a4と一貫していないのは 混乱の元のような気がするが、実は真面目にトラックしている人は いないと思うので問題ない？

_ [SAD][LLVM]llvm-gfortranで複素数の累乗演算子バグ

どうやら直ったらしい

r52825 | baldrick | 2008-06-27 15:55:14 +0200 (Fri, 27 Jun 2008) | 3 lines

The cpow functions take two arguments not one.
Fixes PR2443.

が、amorita branchは GCC 4.2.xでは既にコンパイル不能なのでテストできない罠