Orz日記 by Akio Morita

_ [イベント]リリカルマジカル

行ってきましたw

大きなイベントと違って杖の類もOKなので、 デバイス構えたクロノとかフェイトとか見られました(眼福眼福) あと、フェイトとなのはの制服コンビでDDRとかw

ちなみに、TX浅草駅からだと浅草寺境内を抜けて二天門へ抜けるのが近道

_ [LHC]Transfer Matrixの再構築

使用する軌道応答の数を6から 30まで増やしても、Transfer Matrixの 初期値に誤差を入れた際に収束先がバラつく問題は改善しない。 Transfer Matrix間の距離(行列のノルム)だが、確かに モデルから出発したものと誤差を入れて出発したものの間で 収束後に距離があるのは確かなのだが、出発時の距離から 桁で小さくなってる(接近してきている)。また、Transfer Matrix自体の ノルムを基準に相対距離を見ると1e-7オーダー、応答軌道の フィッティングでの残差は1e-10m台(一部の steering/BPMの組み合わせで1e-8m) なので、評価関数(残差２乗和)を評価する際の有効精度の限界に当たっている？ その場合、真の解周辺にある2次形式な極小が浮動小数点表現の 桁落ちや演算誤差でデコボコしていて、入ってくる経路に依存して 停止位置が変わっていると解釈できる。 少なくとも、初期値に導入する誤差を大きくしていった際に、 あるしきい値を越えると収束後の残差２乗和が有意に劣化して まったく別の極小点へ収束するようになるので、 大域的にはうまくいってるのかな？ (精度が測定の要求に満足するかは別問題だが)

現在は、測定データ側にランダムエラーを入れた際の収束性を検証中

それなりに、使い物になりそうなら、入出力部を書いてプログラム化

_ [SAD]文法の書き下す

バギーな構文解析器を置き換えることを最終目的に、 Yet Anotherな構文解析器を作るために PEGを用いた SADScript自体の文法定義を書き下してテストしているのだが... 抽象構文木の構造が深くなりすぎる。

もう少し、式の項を構成する専用の非終端記号を導入して 入れ子を減らさないと解析結果の検証が大変

構文木から S式へ変換する変換器の開発はその後かな...

_ [hgsubversion]hgsubversion on Python3.7

前回の続き

現状、hg version --svnが動くところまできた

やったこと

• 前回のMercurial 5.4対応パッチを適用
• Subversion bindingは、devel/py-subversion@py37を使う
• 2to3 -w .で書き換える
• --traceback付きで起動して、エラーが出る度に文字列操作まわりの型を修正する
  • Mercurial側のデータセットやAPIは基本bytes型
    • リテラルなら bで前置修飾する
    • str型オブジェクトなら.encode('utf8')してから渡す
  • Python APIは基本str型
    • bytes型オブジェクトは、.decode('utf8')してから渡す

こまめに修正していけば動くようになる模様…だけど、ぶっちゃけ面倒くさい