Orz日記 by Akio Morita

_ [イベント]博麗神社例大祭

上海アリス幻楽団& 黄昏フロンティア合同列だけ入場待機列が 別れていた...上海恐るべし、 冬コミでは西駐車場1周してたし、次の夏コミは専用入場待機列ですか?

上海と黄昏が始めから限壱だったようで、 列の進みが早かったので調子こいて、 COOL&CREATEとか、 dBu MUSICとか列の長いところに並んでいたら、 FLIPFLOPsの新刊ゲットし損ねた Orz

博麗神社例大祭は、オンリーとしては大きめのイベント(500SP)だけど この手の規模の小さなイベントならではの出来ごと発生w Mist Mysterisiaの新刊コピー誌が、 14:00より配布予定だったのだが、人が集まり過ぎてコピー誌を賭けた ジャンケン大会に...会場の片隅でみんなで盛り上がるのって いいですよね

司会者とのジャンケン勝ち残り方式で複数回選抜なので、 一回戦はとにかく同じのを出し続けて確実に通過するのを目指し 二回戦以降は勘で勝負して、一応勝ち組に滑り込み... なぜかイベントのジャンケン勝負は引きが強い気がする

帰りの中継地たる秋葉原のMelonbooksで ゲットし損ねたFLIPFLOPsの新刊を補完

ついでに、USER'S SIDE覗きに行ったのだが、 FANATICの東京ショールーム跡地(東洋ビル 1F)が、 ホワイトキャンバス2号店になっていてびっくり

_ [LHC]軌道レスポンスからβを求める in Transport Line

な話が、持ち込まれて検討中。(厳密にはLHCではなく、CTF3の ビームトランスポートが合わないらしい)

フィット自体は走るのだが結果が思わしくないので、第一原理に戻って よく考えてみると、Transport Lineの場合周期境界条件が無いので、 β(s)/φ(s)が Beamlineの特徴量になっていない(Transport入り口の β(0),α(0)に依存する関数)ので、仮に軌道レスポンスのフィットが 成功してもそこから得られるβ(s)/φ(s)は、あるβ(0),α(0)を Transportに与えた際のβ(s)/φ(s)を得ていることになる。 (厳密には、任意定数λ,Cを含んだλβ(s)とφ(s)+Cが得られる訳だが...)

よく考えれば、当たり前のことだったりする

1. Dipole Kickによる軌道のレスポンスは、Beamlineの写像関数(Transfer Matrix)で決定される
2. β(s)/φ(s)は、Beamlineの写像関数(Transfer Matrix)とβ(0),α(0)の関数
3. 周期境界条件の元では、β(s)/φ(s)は Beamlineの写像関数(Transfer Matrix)のみで決定される

Transport Lineの場合は、三番目の条件が無いので、軌道レスポンスに β(s)/φ(s)をフィットする操作は、R^2の広さを持ったTransport Lineの β(s)/φ(s)の集合から一個の元を拾い上げる操作で、何らかの拘束条件を 課して固定しない限り、望みの解が得られる確率は激しく低い。

フィットの繰り返しの途中で、暫定解を拘束関数で変換するのが 一番簡単な実装と思われるが、線形変換(λ,C)の自由度があるので その変換は非線形変換か sに関して不連続な変換である必要が有る。 また、完全に拘束するには最低2自由度の拘束が必要と思われる。

_ [雑記][FreeBSD]VirtualBox on FreeBSD/amd64

β版だけど動くようになった。

XGAエミュレーションが若干重いけど、コンソールモードだと かなりきびきび動く＆設定管理画面はかなり良さげ

_ [FreeBSD]ZFS version 13 MFC

来たみたいだが、直ぐにアップデートして大丈夫なのだろうか？

ZFS上には、仮想マシンのイメージぐらいしか置いてないので、 壊れても問題は無いけれどねぇ

_ [SAD]Intersection/Complement

sort engine入れ替え後にregressionしたので調査したが、リストをスタック上に展開して舐める際に、空のリストが考慮されていないのが、原因だった

オリジナルコードだと、直前にUnion1をスタック経由で呼び出す際の引数がスタック上に存在するので、無効参照を避けているが、演算結果は結果が正しくない

問題を起こすのは、第二引数が空のリストのケース

Intersection[{3,1,{},2}, {}]

空集合との積集合なので{}を返すべきところを{{}}を返す

Complement[{3,1,{},2}, {}]

空集合を除外するので、{1,2,3,{}}を返すべきところを{1,2,3}を返す

さらに、戻り値の構築をitflistで行うため、スタックが空(空集合)のケースでは、itflistからitfcrelistmへ頭部(ntfoper, mtfleftbrace)で移譲され、itfcrelistmが構築済みのiaxnulll空リストコンテナの参照を返すが、その後にcopyheadで頭部を挿入する過程で、構築済み空リストが汚染されている

_ [SAD]再入可能なqsort(3)

標準化という意味での本命は、ISO C11 Annex.Kのqsort_s(3)だけど実装している環境はFreeBSDやMicrosoftぐらいか？

glibcのqsort_rは戻り値が無い以外は、ほぼqsort_s

次点は、ISO C++にlabmdaで標準化された無形クロージャに対応する機能がISO Cで標準化されることとだが…どうなんでしょう？

実装例的には、LLVM/clangのBlock構文拡張がそのものズバリなのだが…

GCCのNested Function拡張も近いけど、あくまでもローカルスコープ上で定義・参照可能な関数なので、リテラルで引数に積めない、クロージャとして戻り値に出来ないあたりがlambdaやBlock構文拡張に劣る

実用面では、FreeBSDのGitHubからqsort/qsort_sの実装を持ち込む辺りか？

古い教科書には、平均的なケースではオーバーヘッドが多いmergesortはquicksortに勝てない的な言説が書かれているが、現代的なハードウェアでの実測だと比較回数が同程度の状況でmergesortがquicksortに劣る事例は以外と少ない、またその差が小さい模様

初期順序が同一でも比較操作時の間接参照が増えるとquicksortに逆転されることから、キャッシュ階層が深い計算機環境では、mergesortの方がメモリアクセスの連続性が高い(マージ操作)ためにキャッシュ効き易いためではと推測される

ちなみに、heapsortの実行時間は$N\log{N}$で安定だが、quick/mergesortに比べて数倍〜10倍程度遅い模様

$O(N)$の作業領域が安定して確保出来る状況であれば、mergesortを標準にしたほうが良さそうだが、標準実装してるのはBSD系ぐらいで、再入可能なmergesortを標準実装してるのはBlock拡張付きのDarwinとFreeBSDぐらいなのが玉に瑕

_ [Admin]自宅LAN内のアドレス整理

サービス・機材区分毎にCIDRで分割してアドレス振り直し

将来的には、ルータとDHCP・DNSサービス用の小型PC導入して、通信インフラを分離したい…

小型PCを調べてみたが、サバ太郎って意外と高いねぇ… (Intel NUCとかは目的が違うので消費電力がぁ…)

現実解はMaxtang nx6412辺りか？ (能力的には、サバ太郎 Type-N相当)

一応1GBASE-T x2に 最大 32GBのメモリに ストレージはSATA 2.5inch or M.2 SATAなので mSATA系の小型PCより部品の入手性は良さそう