ストレイテナーと確率７では、
”「シャッフルで曲選択していって60分でリセット」を繰り返したら手持ちの曲全部聴き終わるまでにどんだけかかるんだ？”というのを検証した。
結果的にそのときは95回の「60分シャッフル」を繰り返すことで手持ち全曲を聴き終えたのだが、
確率の問題なので100回を超える時もあるし70回で終わるときもある。
ではその平均（最も頻度の高い回数）はどこなのか？というのは前回の終わりで疑問になっていた。
で、今回それを検証してみようと思い立ち、前回のプログラムを少し改造して実行してみた。
ふと思い出したので書いてみる。 昔のPG修正の失敗談である。
UNIX系OSにはunix2dosと、その逆のdos2unixコマンドというのが存在する。
使い方（オプション）はほとんど同じだが効果（？）が違う。
主に改行コードを変換する目的で使用する。
先に述べたiconvコマンドと併用することで、UNIX系OS上でWindows系OS向けのテキストファイルを用意することが出来る。
テーブル・マテビュー・INDEXのDDLを取得して、テーブル（マテビュー）別にファイルに吐きだすスクリプト。
DBMS_METADATA.GET_DDL、DBMS_METADATA.GET_DEPENDENT_DDLをカーソルと併用して使用し、
オブジェクト毎にDDLを取得しつつ、ファイルへの出力はUTL_FILEパッケージで行う。
UNIXには標準でiconvコマンドというのがついている。
コマンド一つでテキストファイルのエンコードを変換してくれる手軽で便利な機能である。
iconvコマンドの使い方を含めて、本項で備忘録のため記載する。
UNIX系OSには、ファイルやディレクトリのタイムスタンプに限界値が設けられており、それを超えると変な日時に逆転してしまう。
⇒いわゆる「2038年問題」にあたる
UTC+9:00の日本において、その限界値は2038年1月19日12時14分頃である。
これを超える（これより未来の）日付を与えて変更しようとすると、
変更自体は可能だが変更結果が1901年12月14日等の変な日時になってしまう。
なお、touchコマンドは対応していない（2039年に変更しようとするとエラーになる）。
与えられた文字列をMD5でハッシュ値に変換する方法のメモ
EXCELのVLOOKUPは与えた検索値を指定範囲から探し出して、指定した列番号の位置の値を取得する関数である
例えば以下↓のようなシート
| A | B | C | |
| 1 | SEX | NAME_ID | NAME |
| 2 | 男 | A | Aさんです。 |
| 3 | 女 | B | Bさんです。 |
| 4 | 男 | C | Cさんです。 |
| 5 | IDを入力⇒ | ※ |
があったとき、B2:C4までを検索範囲として
| A | B | C | |
| 1 | SEX | NAME_ID | NAME |
| 2 | 男 | A | Aさんです。 |
| 3 | 女 | B | Bさんです。 |
| 4 | 男 | C | Cさんです。 |
| 5 | IDを入力⇒ | ※ |
C5セル（※のセル）に以下のVLOOKUP関数を記述
=vlookup(B5,B2:C4,2,false)
と入力すると、
「B5セルに与えた検索値をもとにB2:C4セルまでを検索して引っかかった行の2番目のセルを取得」するという指示になる。
よってB5セルに「A」と入力すれば「Aさんです。」という値が取得できるし
「C」と入力すれば「Cさんです。」という値が取得できる。
（こんな使い方はその辺ググれば出てくるがこの話の前段として…）
ただ、VLOOKUPは与えた検索値をもとにして右方向にしか検索できないので、
指定範囲内における検索値を持った列は一番左側の列に位置している必要がある。
よってこの例でいうと、「A」と与えたら列名「NAME_ID」の列より右側、列名でいうと「NAME」の項目しか取得できない。
つまり、「NAME_ID」より左側にある「SEX」の値を「NAME_ID」の検索値からは取得することが出来ない。
例えば以下のような検索範囲
| A | B | C | |
| 1 | SEX | NAME_ID | NAME |
| 2 | 男 | A | Aさんです。 |
| 3 | 女 | B | Bさんです。 |
| 4 | 男 | C | Cさんです。 |
| 5 | IDを入力⇒ | ※ |
において、C5セルに以下のVLOOKUP関数を記述
=vlookup(B5,A2:B4,0,false)
と入力してB５セルに「A」と入力しても、「男」という値は取得できない。
これは「A」で検索して引っかかった行の1つ左側のセルの値を取得しろ（つまり「SEX」列の値を取得しろ）という指示として無理矢理記述しているが
逆方向への検索にVLOOKUPが対応していないので、#N/Aになってしまう。（第三引数が1以上でないと関数が受け付けない）
ここまでが前置き。
要するに単純なVLOOKUPでは右側への検索しかできない。
検索値より左側にある列の値は、事前に右側にコピペしておくか、数式で参照させるなどして、
とにかく検索値より右側にしないとVLOOKUPでは検索できないのである。
これを、検索値より左側にある値をそのままにして、MATCHやINDEX、INDIRECTを使って検索する方法を実現する。
前回のやつは、
テーブル名を与えたらそのテーブルの全項目に対するNVL(LENGHB(COLUMN_NAME),0)を作ってくれるが、
その後先頭に「SELECT」と最後尾に「FROM [テーブル名]」を自分でつけて自分でSQLを流すという作業が必要だった。
そこまで含めて完全自動化できそうだったのでやってみた。
なんかシャッフルで聴いていると
重複度が２以上の曲A（シングルとアルバムで２つ持ってるとか）があったとき、
あるタイミングでAが再生されるとその次かその次の次あたりでまたAが流れることが多いように感じる。
例えばストレイテナーと確率１ではSILLY PARADE（重複度２）の連続再生確率を計算したが、
その確率は約0.00367%という結果になっており、100000回（10万回）に３回くらいしか起きない。
この値からすれば「連続再生」はかなりレアだと思うのだがどうも聴いているとよくこういう現象にあたる気がしてきた。
「直近で聴いたことあるから耳に残ってる」ということで印象に強く残るのかもしれないが、
そもそも連続再生に対する遭遇率が低いんだし、現象が発生しなければ印象に残るもくそもないと思うのだ。
SILLY PARADEは重複度２なので、１曲どこかで再生されると残りは１曲となり、
それがしかも連続するとなるとかなり低確率であることは計算するまでもなく感じ取れるが、
ストレイテナーと確率５で確認した結果では手持ちのストレイテナーには重複度３の曲（CLONE等）もあり、
こっちの連続再生はSILLY PARADEに比べれば少し高い感じもする。
また、冒頭述べたように、「連続」でなくても、
CLONE⇒（なんか別の曲）⇒CLONEというように間に１～２曲挟むパターンにもよく遭遇する印象がある。
こういったパターンも加味して、今回は「連続の確率」というのに着目してみたい。