これはKAZOONの不定期日記(チラシの裏)の2016年版です.下に行くほど新しいです. 2016/1/3 更新履歴 あけましておめでとうございます. 新年一発目の更新はバグフィックス. 新ブタンとヘプタンの Tournament が動かなかったバグを修正しました. 2016/1/4 更新履歴 昨日バグフィックスしたばかりですが,エタン・ブタン・ヘプタンの Tournament の実装を一新し,高速化しました. トーナメント戦を進める方法自体は同じですが, 勝敗結果の取り出しなどにおいて,計算効率を意識した書き直しを行いました. これにより従来より5倍程度高速化されました. 2016/1/6 更新履歴 マーガレット用語集のリンク修正及びいくつかの用語の追加,訂正を行った. また,マーガレットからヴォイドまでの公式ルールの差分早見表を公開した. 2016/1/7 更新履歴 用語集を更に修正. 2016/2/12 更新履歴 最近のエタンの書き直しに合わせて,エテンを書き直しました. 近いうちに多並列化のための更新ができればと思っています. なお,現バージョンで 15/0/0/5/護衝熱衝絶熱速/紫電@二回戦 の固度が10であることを確認しました. 固剣師は 5/0/0/3/護速速魔鏡鏡 および魔鏡の並び違いの全3種(実質1種)です. 2016/2/17 更新履歴 エテンを修正し,並列化効率が大幅に向上しました. 依然としてオーバーヘッドロスは無視できるほど小さくはないものの, スレッド数を4以上に増やしても,(それに見合うコア数があれば)それなりに実時間が短縮されるようになりました. 次の課題は枝刈りの強化ですが,これは一朝一夕ではなんともなりませんね. 2016/2/18 更新履歴 エテンの致命的なバグを修正しました. まだバグを含んでいるかもしれないので,お気をつけてご利用ください. 2016/2/19 更新履歴 今日もエテンの更新です. 今回は 5/0/0/1/ をスキップできるようにしました. main.c を書き換えるとより詳細に探索する剣技の範囲を指定できます. 詳しくは readme.txt を御覧ください. 2016/2/26 更新履歴 エテンの更新です.主に時間計算量削減のための修正を行いました. search()が直前のバージョンの約2倍に高速化されています. 2016/3/3 更新履歴 ターン0で死亡判定を行っていたエテンのバグを修正しました. ターン1以降であることの判定がばかにならないほど重かったため, ターン0専用の処理関数を実装し,若干の高速化も図られました. 2016/3/15 更新履歴 エテンをほんのり高速化のために修正. エタンのちょっとしたバグ(戦闘への影響なし)を修正. 2016/3/21 更新履歴 エテンを更新. 主な変更点として number_of_threads と x_size を search の引数にし, デフォルトの main で ./ethene.ini からこれらの値を読むようにした. 2016/3/25 更新履歴 エテンを更新. いくつかの細かなバグの修正を行った. また,search() の引数の一部を構造体にまとめた. 探索スレッドの待機方法を変更したが,現状では特に意味はない. 2016/3/26 更新履歴 エテンの小さなバグを修正. 2016/3/27 更新履歴 エタンとエテンを融合した Ruby の拡張ライブラリ,ポリエテンを公開. さらに雑記を新設し,Ruby拡張ライブラリ関連備忘録を公開. ポリエテンは自分でいろいろいじるには拡張ライブラリに関する知識がある程度必要であるため,ハードルは高い. しかし,入力データの差し替え等の操作を C でなく Ruby で書け,純粋なエテンに比べて圧倒的に使いやすい. 実行時間としては,Ruby の起動等のオーバーヘッドはある程度あるが,計算本体は基本的にエテンと変わらない. 見切り発車気味でろくにテストしてないので,不具合があれば教えてほしい. また,ドキュメントはそのうち何とかするつもりだが,わからない所があれば気楽に聞いてほしい. 2016/3/31 更新履歴 ポリエテンの malloc まわりを修正し,より安全に処理できるようにした. 追記: さらに修正.TaNode.car の型がポインタではなく実体となり,若干の非互換性を生じる修正となった. 2016/4/6 更新履歴 エタン,エテン,ポリエテンを少し修正. ポリエテンのオンラインマニュアルを整備した. また,Ruby拡張ライブラリ関連備忘録も更新し,いくつか情報を追加した. 追記: エテンとポリエテンのバグをそれぞれ修正. 無限ループは,その,i と 1 って似てるよね……. 2016/4/9 更新履歴 エテンとポリエテンを更新. あいざわ・オランダ判定を改良した. 改良にあたり,簡易あいざわ判定の  7. これまでに確認したリミテッドでない剣の起動遅延数をソートしたとき,遅延の少ない方から素早さ番目の遅延数を,新たな許容遅延数とする. をどうするかが悩ましい課題だったが,バケットソートを使うことで,比較的スマートに解決できた. すなわち,現在注目している遅延1の剣の数,遅延2の剣の数,遅延3の剣の数,遅延4の剣の数という長さ4の配列を使い, 新たに剣を見るたびに新しい剣の遅延数に応じてバケツの中身を増やし,最も遅延の大きいバケツの中身を減らせばよいのである. これにより,許容遅延数が,中身のある最も遅延の大きなバケツの遅延数であることが保証される. 2016/5/2 更新履歴 エテンとポリエテンを更新.また,この更新にともなってポリエテンオンラインマニュアルも更新. エテンは厳密あいざわ判定をやや改良し,高速化した. ポリエテンはエテンの更新の反映に加え,ymalloc() の実装を大幅に変更した. 従来の ruby_xmalloc() を GC 禁止状態でサブスレッドから呼び出す方法は,一見うまく行っていた. しかし,ymalloc() を大量に呼び出した場合,クラッシュすることが判明した. クラッシュの原因を完全に突き止めることはできなかったが, 特殊な ruby_xmalloc() の呼び出しが原因として疑われ, 今回の修正によってクラッシュが回避されたため,間接的ではあるが,これが原因と断定した. Ruby スレッドに対応していないネイティブスレッド上のあらゆる Ruby-API の使用はやはりご法度というわけだ. ちなみに ruby_mimmalloc() はこういうシーンで使えるかと思いきや,ruby.h で公開されていない上,バグのある実装なので使えない. 基本的に,ruby_mimmalloc() またはその類型と ruby_xfree() を組み合わせるのはやはり難しい. やはり ruby_xmalloc() と ruby_xfree(),malloc() と free() のいずれかの組み合わせを徹底するのが安全である. しかし,ポリエテンの場合 pe_ta_clear() の実装の都合で,ruby_xmalloc() で確保したか ymalloc() で確保したかにかかわらず, 同じ free 系関数を使いたいという要求があり,ymalloc() を,間接的に ruby_xmalloc() を呼ぶ実装にした. サブスレッドで呼ぶのが問題なので,条件変数を使ってメインスレッドで呼び出す形にすることで問題を回避することにしたのだ. その結果,ymalloc() のオーバーヘッドはかなり増大したが,もともと頻繁に呼び出すものではないので妥協した. どうしても proc 内部でメモリを確保する必要があり,しかもその頻度が高くてパフォーマンスが気になる場合は, ymalloc() を使わず,malloc() と free() を直接使うなどを試してほしい. 2016/5/11 更新履歴 よろろろさんから連絡があり,フリーティケットシアターがサービス終了していたことを知る. その移転に伴いリンク先を修正した. ついでに F-ZERO GX のインデックスページも一部修正. フリーティケットシアターはかのむうむ氏の気まぐれリプレイうpサイトの提供元でもあり, F-ZERO GX 界隈でよく用いられていたサービスであった. 当時の GX 関連の攻略情報がまた闇に埋もれたことになる. よよよろさんのように移転してくれればいいのだが……. 2016/5/18 高速廻転寿司 名前の通りの一発ネタ.とは言え,ここで紹介してもいいと思う程度には良く出来ていた. 寿司をマシンとして操るレースゲームで,寿司下駄を思わせる木目の立体コースを走る. 立体コースとはいえ,基本的に測地線にそって動き,完全にコースに張り付いた F-ZERO 調のシステムである. ブレーキなしで,アクセルとデジタルステアリングの3ボタン制. ステアリングはよくあるデジタルステアものの,スライド込みのような動きをする. 良かった点 ・十分スピード感がある ・コースは5つと程よく,コースの特徴等も違和感がない ・マシン(寿司)は13種とやたら多いが,ネタとして楽しい ・比較的素早くリスタートできるのもよい ・ゴールマーカーは湯のみで「あがり」と掛かっていてよい ・コースアウトは自動復帰式で,落ちやすいシステムとの相性はよい 悪かった点 ・コース選択がカーソル記憶でなく,リスタート時に再選択の必要がある ・敵機が完全にヤクモノ扱いで,競争相手の体をなしていない ・ヤクモノである逆走する馬はストレスしか生まず,ネタとしても意味不明 ・ダッシュプレート的なヤクモノが1万円札で,回転寿司とのネタ相性は微妙.  ガリや醤油が使われていないので,これらのほうがよかったのでは ・コース外はレンダリング的には存在するが,ゲーム物理的にはなく,  飛び出した後コース上の空中にいても自動復帰する.  せっかくの立体コースなのに,という気がしてしまう ・スライドこみのステアリングは好みでない スライドを含むデジタルステアは,ステア連打による緩いカーブのインベタがやりにくく,好きでない. そこへ行くとやはりペンタ氏の RACE GAME はよく出来ている. MAX や eXceeDrive の割りきった「スキー式」のステアリングシステムも悪くない. ステア入力によってマシンが旋回し,それによって軌道が曲がる,というのが自然なのだ. F-ZERO のスライドは,ステアとは独立に存在するので問題ない. 問題なのは,スライドターンしか存在しないケースなのだ. で,そんなに私が嫌いなこのタイプのデジタルステアが「よくある」ということは, おそらくこのタイプが好きな人というのも一定数いるのだろう. このタイプは,カーブに「さしかかってからはじめて」ステア入力すると綺麗に曲がれるので, カーブが来てから「あ,曲がろう」と思う人にとってはこちらのほうが自然なのかもしれない. でもやっぱり,カーブに備えてラインを整え,ステアを切ってからカーブに突入するほうが気持ちいいのだけどな. とまあ不満な点はあれど,ネタゲーとして十分よく出来ているといってよい. 2016/5/20 更新履歴 むうむさんのサイトが落ちてるっぽいのでリンク先を移転前のものに変更. 2016/6/10 更新履歴 巡り廻るの雑記に少し追記. 2016/11/15 更新履歴 だいぶ前にリプライ送ったけど無視されたので,不偏分散の分散の推定についての考察PDFを正式に公開することにした. 気が向いたら雑記も充実させていきたいところ.