画面遷移なしの判定のみ、というｉケバブ簡易版の作成に着手。ただし手を抜かずにクラス構成はするし、連撃モードのOn/Offボタンは実装。このまま改良してｉケバブ完成版になれば・・・と思ってはいる。

UITableViewのセルを３種類自作。半汎用部品に仕上げる（設定画面などで重宝するのだ）。
このテストが上手くいったので、次からはいよいよ？ｉケバブの本格的な前哨戦（判定を行うだけ）が多分始まる・・・

ここ数日クラスがどうの、必要なメソッドとプロパティがどうのとか目に見えないことばっかりやってたので進捗報告があまりできない状態。
本当はメソッドの動きについても文字に起こしておかないといけないんだけど…そこまでやるとさすがに面倒なので放置するかなぁ。
　
土日はちょっと離れてｉドッジこと神語リストの改良にイソシム方向にしようかと。
データの補填と幻鏡術対応が主。

　
従前のケバブDSの様式を踏襲した画面レイアウトを作ってみた。とりあえずコンポーネントをおいてみたハリボテ段階。
実際に作ってみるとボタンが多いなぁと本当に思う。
ごちゃっとしすぎないということは１画面に判定と判定結果をまとめないということであり、そのときに判定の操作が煩雑になる（画面遷移が増える）ということである。
画面遷移をするバージョンについても考えないといけないなぁこりゃぁ・・・。

自作メルセンヌ・ツイスタライブラリ（つーても元コードから必要なコードをObjectvie-Cにしただけ）の検証。
１０００個振った結果と、連続した１０回ごとに「半数以上が同じ出目」のチェックを行わせたのだけど、いまいちな結果になっている。
　

　
「連続した１０回」は１０００回の試行で１００回チェックされるのだが、スクショの例とかを見てもおよそ１割くらいがこのチェックに引っかかってる。正直言って「目につく」と感想が漏れるレベルだと偏りの激しさは結構なものになりそうな気がする。
逆に出目そのものはそれなりの範囲でぶれているが、気持ちの上（数学的でなくてゴメンナサイ）では問題なさそう。
つまり、「出ないときは出ない、出るときは出る、試行回数が多いと偏りがならされる」ってところですかね？
以前よりゆっけ氏からは「（プログラムでやると）出目の偏りはげしくね？」と言われているので、こういう検証をしてみたのだが、言われた通りになってちょっと頭を抱える。
本来小数乱数である乱数を整数化するところでちょっといろいろいじる必要がありそうだなぁ・・・。
　
＃０９／０１／０６　０３：１９追記
計算が乱暴なんだが、「特定の出目が５つ偏る率」をやってみたら7.8%と言われた。６個以上の偏りも当然考えないといけないのだが、１０％くらいは半分が同じ出目に偏るって、案外あるのかもなぁ・・・
　

ライセンスのアクティベーションのメールが来ない。米国時間では金曜の昼だが、日本時間の土曜日なのがマズったかなぁ。

メモリ確保の仕組みが分からない。というか「いつ、どこで、誰が、どのように、何のために」ソースで確保すると明示したポインタの領域を破壊するんだよ。
おそらくソースにかかれていない「Ｖｉｅｗのロード後」で「神語リストのテーブルの表示前」の外部処理がアホやってるらしいのだが。
しょうがないのでダミーメモリ確保したまま（リーク判定もされないし）強行突破してみた（別名：放置）。
　
これだから！　開発者ってヤツは！

ざくざくと作ってて１カ所気になったというか、デバッグしてて気がついた点。
どういうロジックで作ってても、メモリの特定の領域（？）でalloc（メモリ確保）してしまったものが変に上書きされるらしい。
それはどうよ！と声を大にしていいたいが、XMLからのデータを読み込むタイミングをずらす必要があると見た。
　
というのはダミーの配列をallocしたらエラー回避できたとかいうあほらしい結果だったので・・・うーむ。

Navigationベースの画面遷移について学んだ。というのはこの方法にすると「Back」ボタンがいとも簡単につく（笑）
これを先の神語術表示DBに組み込んでおけばOKというわけです。
　
割とアイディアが浮かんできたので、この後もいろいろ実験的プログラムを作ってみようと思う今日この頃。
　
＃乱数生成ロジックを作りたくないだけ、という説。