IT

ストレイテナーと確率６（３の続き）

IT

ストレイテナーと確率３（「CLONEをよく耳にする」のは事実なのか？）の続き。

前回は「CLONE」という曲だけに着目したが、これを別の曲にしたときの考察を実施してみる。
手持ちのストレイテナー全２５７曲の中で、インスト除くと３つある「CLONE」は、
1つ目：平均64曲目、2つ目：平均128曲目、3つ目：平均192曲目
にそれぞれ選択されるということが前回の検証でわかっている。
CLONEは重複度３だったが、重複度が異なる別の曲だとどういう結果になるのか？
を試してみたくなった。

前回の結果を見て疑問に思ったのは、
1つ目：平均64曲目
2つ目：平均128曲目
3つ目：平均192曲目
というように、その差がきれいに64になっていることだった。
CLONEの重複度は３だから、
他の重複度の曲でやるとどうなるのか？実験してみたい。
ちなみにCLONE前提で考えていたので「どの曲か」の判定文字列はソースコードにべた書きしている。
ちょっと直してコンパイルかけるだけだからそれほど苦でもないが
こういう検証をするにあたっては外部から引数等でもらうつくりにした方が良かったなと感じた。（だが直さない）
※ただ、「ストレイテナーと確率３」で使用した検証用プログラムにおける
　１試行結果を書き出す処理「（３）シミュレーション　メイン処理」は
　曲が可変（つまり重複度が可変）になることを想定してListを使用していたので
　曲名部分の固定値を変えるだけで対応可能にはなっている

 

ストレイテナーと確率５（２と４の続き、まとめられる曲をまとめて再検証）

IT



前回↓の続き。
ストレイテナーと確率２
ストレイテナーと確率４

前回の検証では、集計のKEY判定を収録されている曲名の文字列だけで行っていた。
よって、実際には（ほぼ）同じ曲なのに別々の曲として集計されていたり、
一方でオリジナルとアコースティックアレンジで別の曲なのに曲名が同じというだけで同じ曲として集計されていたり、
といった点が若干の心残りとしてあった。
（当時は「面倒くさい」で片づけた）

実例を挙げると（上記記事内でもちょこっと書いてあるが）、
Dear Deadman収録の「Melodic Storm-DEAR EDIT-」はシングルの「Melodic Storm」とほぼ同じだが曲名が異なり、、
TITLE収録の「REBIRTH」はSOFT収録の「REBIRTH」とまったく違うが曲名が一緒。
このため、Melodic Stormの集計範囲からはDEAR EDITは除外されているし、
REBIRTHはオリジナルとアコースティックで全く違うが同じ曲として集計されている。

実際に聴いているときは、曲名ではなくその曲の中身で「どの曲か」を判別しているはずである。
よって、上記の「違い」を加味して、前回行った検証を再実施してみようと思う。
これは、「CLONEをよく聴く気がしてならない」というモヤモヤとしたものが晴れない自分を納得させるためのものである。
⇒この判別を正せば、ひょっとしたらCLONEが選ばれやすさ１位になるんじゃあねーか！？という淡い希望を抱いている


 

【ORACLE】分散トランザクションについて

IT

前に書いた記事の詳細を補足する（見返したら自分で良くわからなかったので）。

舞台となるのは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をかけた直後、
　そのトランザクションは「分散トランザクション」になる。


 

ストレイテナーと確率４（ｎ曲目には何が選ばれやすい？）

IT



前回の続き。

前回は「CLONEの選ばれやすさ」というのに注目して、楽曲に限定した検証を行ったが、
今回は「曲順」という観点で検証をしていきたい。

手持ちのストレイテナー全曲の中で、インスト除くと「CLONE」は３つあるが、
３つ目の「CLONE」は平均して192曲目までには選ばれる、
というのが前回のシミュレーションでわかった。
同様の考え方が他の楽曲に関しても言えるのであれば、
曲順が進むにつれて「選ばれやすさ」にも変化が起こり、
前半・中盤・後半とでは楽曲別の「選ばれやすさ」も変わってくるのでは？
という疑問から検証をしてみたいと考えた。
例えば１曲目なら257曲の中からランダムに選ぶだけだが、
10曲目、50曲目、100曲目…と進んでいく中では、次に選ぶ曲の選択肢も変化しているはずだから、
楽曲単体（シングルとアルバムで完全に区別をつける）で見れば完全ランダムだとしても、
シングル集計・アルバム集計と、括りを付けて集計していくとその結果も変化するのではないだろうか。
あるいは、リスト内に占めるその集計単位の数（構成比）と一致するのか？

というわけで、その検証をしてみる。

 

【ORACLE】サブパーティションプルーニングのバグ

IT

有識者との問い合わせのやり取りの中で発覚した、結論からいうとOracleのバグらしいのだが、
俺自身がよくわかっていないので情報整理する意味で書いてみる。
内容としては、厄介なことに同じSQLでも結果が異なるケースをもたらすようだ。

 

ストレイテナーと確率３（本当に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に減るわけではない）。