前に書いた記事の詳細を補足する（見返したら自分で良くわからなかったので）。
舞台となるのはDB LINKでつながっている２つのDBである。（↓のようなイメージ）
●LOCAL DBには「TABLE_A」というテーブルと、「SYNONYM_B」というシノニムがある。
SYNONYM_BはDB LINKを経由してREMOTE DBの「TABLE_B」に繋がっており、
LOCAL DB側に実体はない。
●REMOTE DBには「TABLE_B」というテーブルがある。
このDBはそれ単体で閉じており、DB LINKを経由してLOCAL DBを参照することはない。
●このとき、LOCAL DBに接続してSYNONYM_Bに対してSELECTをかけた直後、
そのトランザクションは「分散トランザクション」になる。
前回の続き。
前回は「CLONEの選ばれやすさ」というのに注目して、楽曲に限定した検証を行ったが、
今回は「曲順」という観点で検証をしていきたい。
手持ちのストレイテナー全曲の中で、インスト除くと「CLONE」は３つあるが、
３つ目の「CLONE」は平均して192曲目までには選ばれる、
というのが前回のシミュレーションでわかった。
同様の考え方が他の楽曲に関しても言えるのであれば、
曲順が進むにつれて「選ばれやすさ」にも変化が起こり、
前半・中盤・後半とでは楽曲別の「選ばれやすさ」も変わってくるのでは？
という疑問から検証をしてみたいと考えた。
例えば１曲目なら257曲の中からランダムに選ぶだけだが、
10曲目、50曲目、100曲目…と進んでいく中では、次に選ぶ曲の選択肢も変化しているはずだから、
楽曲単体（シングルとアルバムで完全に区別をつける）で見れば完全ランダムだとしても、
シングル集計・アルバム集計と、括りを付けて集計していくとその結果も変化するのではないだろうか。
あるいは、リスト内に占めるその集計単位の数（構成比）と一致するのか？
というわけで、その検証をしてみる。
有識者との問い合わせのやり取りの中で発覚した、結論からいうとOracleのバグらしいのだが、
俺自身がよくわかっていないので情報整理する意味で書いてみる。
内容としては、厄介なことに同じSQLでも結果が異なるケースをもたらすようだ。
前回の続き。
前回は「60分以内にどの曲が選ばれやすいか？」というのをシミュレーションした。
１．シングル・アルバムで重複している曲程選ばれやすい
２．演奏時間が短い曲程選ばれやすい
以上の２点が「選ばれやすさ」－選択頻度－を上げる要因になっていることがわかった。
結果的に、１．の点において４つの重複を持つ「SIX DAY WONDER」が堂々の１位となった。
なったわけだが、その後も何度かシャッフル再生し続けていたらやっぱりどうもCLONEを耳にする頻度が高い気がしてならない。
前回の検証においてはCLONEは重複点と演奏時間の関係上、選ばれやすさでいえば１１位だったが、
この前なんか10曲目CLONE（CREATURES）⇒11曲目（忘れた）⇒12曲目CLONE（ベスト）という並びになったのだ。
本当にCLONEの選ばれやすさが１１位なら、相当レアな確率を引き当てていることになる。
というわけで今回は視点を変え、「CLONE」という曲に着目して、
”本当にCLONEは選ばれやすいわけではないのか？”というのを考えてみたいと思う。
個人的にいまいち使い勝手が悪いWindowsコマンドプロンプトのfor文のメモ。
（Linuxに慣れすぎているせいだろうなんだろうな…）
OracleのRANK関数－いわゆる「順位」をつけるための関数－の使い方の個人的なメモ
基本的な使い方はSELECTの項目内に以下のように記述する↓
rank() over(order by COLUMN_NAME [ASC|DESC] )
という感じ。
・何か指定できるみたいだが、この使い方だと同値は同順になり、次の値から重複した分を加味した順位になっていく。
・検索結果は、over()内に指定した順序で並び替えられるので、通常順序付けにあたって最後部につけるORDER BYは不要。
勘違いしていたというか、内心ちょびっとだけ「そんなにうまくはいかないか」と思っていたら実際そうだったんだが、
java.util.Listは=で同じ型の別変数に移しても内容が維持されるらしい。
２つの異なる変数間で同じメモリの内容を共有するようになるというか。
例えば、List（変数名：list）で5つの要素を格納した後、
別のList（変数名：list2）にlistをそのまま移して、
list2側でremoveかけると、list2もlistも要素数が4になる（list2だけ5⇒4に減るわけではない）。
javaで時間を加算する実装例。
ストレイテナーのシミュレーションするときにテスト的にやったのでメモとして残す。
特に「時」（Hour）の部分がない文字列からDateFormatを通して時間に変換した後、別の時間と合計する場合は、
オフセットを適切な箇所に加算ないし減算してあげる必要がある。
これは、「時」の部分がない文字列のDateFormat#parseでは1970/01/01 00:00:00をもとに変換されたDateインスタンスを得るからである。
よって、基準となる1970/01/01 09:00:00からすると過去の日時であるため「負数」となり、
これを単純加算していくと負数＋負数でどんどん小さくなり、結果的にわけのわからん時刻になる。
例えば47分2秒＋14分58秒だが、当然だが「1時間2分0秒」という値がほしいのに対し、
オフセット加算をしないと「16時間2分」になる。
これは、
47分 2秒＝1970/01/01 00:47:02＝-29578000ミリ秒
14分58秒＝1970/01/01 00:14:58＝-31502000ミリ秒
で、合計すると-61080000ミリ秒となり、
1970/01/01 09:00:00からすると「過去の日時」を指すことになるので、
結果的に「1969/12/31 16:02:00」になる。
これをHH:mm:ssでパースして「16:02:00」、つまり「16時間2分」になってるように見えてしまうのだ。
前回の続き（？）で再び「iPhoneシャッフルでストレイテナーを再生」するときの考察をしてみる。
今回は「60分という制限時間内でどのアルバム・曲が一番聴かれる可能性が高いのか？」という点に着目してみたい。
この「60分」という制限時間は前回書いた通り俺の会社への出勤（または帰宅）にかかるDoorToDoorの時間とほぼイコールである。
要するに「１回の出勤においてシャッフルで曲を聴いた場合一番よく聴いているのはどのアルバム・曲か？」というのを調べる。
これは普段何気なく聴いているだけだと実際のところあまり気に留めていないが、
巨視的な視点で見たときには数学における確率の諸法則に従っているはずである。
ここでは、シャッフル再生が完全ランダムな曲順を保証するという前提で、
乱数によりシミュレーションを行うプログラムを作成し、いわゆるモンテカルロ法で結果を評価する。
※ちなみに最新アルバム「Behind The scene」は検証の対象に入っていません