2014

ストレイテナーと確率３（本当にCLONEは「よく耳にする」わけではないのか？）

IT



前回の続き。

前回は「60分以内にどの曲が選ばれやすいか？」というのをシミュレーションした。
１．シングル・アルバムで重複している曲程選ばれやすい
２．演奏時間が短い曲程選ばれやすい
以上の２点が「選ばれやすさ」－選択頻度－を上げる要因になっていることがわかった。
結果的に、１．の点において４つの重複を持つ「SIX DAY WONDER」が堂々の１位となった。

なったわけだが、その後も何度かシャッフル再生し続けていたらやっぱりどうもCLONEを耳にする頻度が高い気がしてならない。
前回の検証においてはCLONEは重複点と演奏時間の関係上、選ばれやすさでいえば１１位だったが、
この前なんか10曲目CLONE（CREATURES）⇒11曲目（忘れた）⇒12曲目CLONE（ベスト）という並びになったのだ。
本当にCLONEの選ばれやすさが１１位なら、相当レアな確率を引き当てていることになる。
というわけで今回は視点を変え、「CLONE」という曲に着目して、
”本当にCLONEは選ばれやすいわけではないのか？”というのを考えてみたいと思う。

 

【ORACLE】RANK関数

IT

OracleのRANK関数－いわゆる「順位」をつけるための関数－の使い方の個人的なメモ


基本的な使い方はSELECTの項目内に以下のように記述する↓

rank() over(order by COLUMN_NAME [ASC|DESC] )

という感じ。
・何か指定できるみたいだが、この使い方だと同値は同順になり、次の値から重複した分を加味した順位になっていく。
・検索結果は、over()内に指定した順序で並び替えられるので、通常順序付けにあたって最後部につけるORDER BYは不要。


 

【java】Listについて

IT

勘違いしていたというか、内心ちょびっとだけ「そんなにうまくはいかないか」と思っていたら実際そうだったんだが、
java.util.Listは=で同じ型の別変数に移しても内容が維持されるらしい。
２つの異なる変数間で同じメモリの内容を共有するようになるというか。

例えば、List（変数名：list）で5つの要素を格納した後、
別のList（変数名：list2）にlistをそのまま移して、
list2側でremoveかけると、list2もlistも要素数が4になる（list2だけ5⇒4に減るわけではない）。

 

【java】時間の加算とオフセットの扱い

IT

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分」になってるように見えてしまうのだ。


 

ストレイテナーと確率２

IT

前回の続き（？）で再び「iPhoneシャッフルでストレイテナーを再生」するときの考察をしてみる。
今回は「60分という制限時間内でどのアルバム・曲が一番聴かれる可能性が高いのか？」という点に着目してみたい。
この「60分」という制限時間は前回書いた通り俺の会社への出勤（または帰宅）にかかるDoorToDoorの時間とほぼイコールである。
要するに「１回の出勤においてシャッフルで曲を聴いた場合一番よく聴いているのはどのアルバム・曲か？」というのを調べる。

これは普段何気なく聴いているだけだと実際のところあまり気に留めていないが、
巨視的な視点で見たときには数学における確率の諸法則に従っているはずである。
ここでは、シャッフル再生が完全ランダムな曲順を保証するという前提で、
乱数によりシミュレーションを行うプログラムを作成し、いわゆるモンテカルロ法で結果を評価する。

※ちなみに最新アルバム「Behind The scene」は検証の対象に入っていません

 

ストレイテナーと確率（iPhoneシャッフルとはぐれメタルを仲間にする確率との対比考察）

IT

通勤や帰宅時、または一人での外出時では、
基本的にiPhoneのシャッフル機能を使ってストレイテナーをアーティスト選択して再生している。
シャッフル再生というのが、”完全にランダムに曲順を決めている”という前提だと、
極稀に「おお…この曲が連続して流れるのって結構レアなんじゃあねーかッ！」と思う組み合わせに遭遇することがある。
ただいつもは数値的にそのレア度を評価したわけではないので、その時は「なんとなくレアかも」くらいにしか感じていない。
ちなみに今日なんかはSILLY PARADE(インスト)⇒SILLY PARADE(シングル)が連続して流れた。
気になったので確率を計算してみたらかなり天文学的確率だった。