【java】文字列をMD5ハッシュ化
与えられた文字列をMD5でハッシュ値に変換する方法のメモ
与えられた文字列を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)
と入力してB5セルに「A」と入力しても、「男」という値は取得できない。
これは「A」で検索して引っかかった行の1つ左側のセルの値を取得しろ(つまり「SEX」列の値を取得しろ)という指示として無理矢理記述しているが
逆方向への検索にVLOOKUPが対応していないので、#N/Aになってしまう。(第三引数が1以上でないと関数が受け付けない)
ここまでが前置き。
要するに単純なVLOOKUPでは右側への検索しかできない。
検索値より左側にある列の値は、事前に右側にコピペしておくか、数式で参照させるなどして、
とにかく検索値より右側にしないとVLOOKUPでは検索できないのである。
これを、検索値より左側にある値をそのままにして、MATCHやINDEX、INDIRECTを使って検索する方法を実現する。
前回のやつは、
テーブル名を与えたらそのテーブルの全項目に対するNVL(LENGHB(COLUMN_NAME),0)を作ってくれるが、
その後先頭に「SELECT」と最後尾に「FROM [テーブル名]」を自分でつけて自分でSQLを流すという作業が必要だった。
そこまで含めて完全自動化できそうだったのでやってみた。
なんかシャッフルで聴いていると
重複度が2以上の曲A(シングルとアルバムで2つ持ってるとか)があったとき、
あるタイミングでAが再生されるとその次かその次の次あたりでまたAが流れることが多いように感じる。
例えばストレイテナーと確率1ではSILLY PARADE(重複度2)の連続再生確率を計算したが、
その確率は約0.00367%という結果になっており、100000回(10万回)に3回くらいしか起きない。
この値からすれば「連続再生」はかなりレアだと思うのだがどうも聴いているとよくこういう現象にあたる気がしてきた。
「直近で聴いたことあるから耳に残ってる」ということで印象に強く残るのかもしれないが、
そもそも連続再生に対する遭遇率が低いんだし、現象が発生しなければ印象に残るもくそもないと思うのだ。
SILLY PARADEは重複度2なので、1曲どこかで再生されると残りは1曲となり、
それがしかも連続するとなるとかなり低確率であることは計算するまでもなく感じ取れるが、
ストレイテナーと確率5で確認した結果では手持ちのストレイテナーには重複度3の曲(CLONE等)もあり、
こっちの連続再生はSILLY PARADEに比べれば少し高い感じもする。
また、冒頭述べたように、「連続」でなくても、
CLONE⇒(なんか別の曲)⇒CLONEというように間に1~2曲挟むパターンにもよく遭遇する印象がある。
こういったパターンも加味して、今回は「連続の確率」というのに着目してみたい。
昔TeraTermマクロ(.ttl)を使う機会があったので少し勉強した。
備忘のためそのメモを載せる。
Tera Termでサーバに接続してから行う一連の動作を「.ttl」というファイルに専用の文法で記述することでマクロ化することができる。
Tera Termの作者のページにリファレンスが載っている。
ストレイテナーと確率2では、
「60分以内に聴けるストレイテナーの曲は約14~15曲」という検証結果が出ている。
この「60分」とは、俺の1回の出勤ないし帰宅にかかる時間である。
ただ、1回の出勤で1からスタートして60分聴いた後、
その帰りにまた1からスタートして60分聴く、
というのは実はあまりやってない。
ある日の出勤時に1からスタートして聴き始めたら、
その帰りは出勤時の最後に聴いていた曲の続きから、
その翌日の出勤時は前日の帰宅時に聴いていた曲の続きから…、
という感じでいつも聴いている。
だから一回シャッフルで聴き始めたら最後の曲を聴き終わるまで基本的にリセットしていない。
※厳密に言うと”そういう聴き方をしていることが多かった”である。
今までの検証の流れを受けて現在は、
毎回リセットして60分以内に聴く曲を記録しているからである。
シャッフルでスタートして最後までリセットせずに聴き続ければ、
中の順番はランダムでも、(リピートしない前提で)手持ちの全楽曲の演奏時間の総和分、聴き続ければ、全曲聴いたことになるが、
60分聴くたびに毎回リセットして次また1からシャッフル再生…
とやっていけば当然前回までに聴いた曲が今回のシャッフル再生に入る可能性があり、
こういう聴き方をしていたら全曲聴き終わるまでどれくらいかかるんだろう?
というのがふと気になってシミュレーションしてみたくなった。
ちなみに手持ちのストレイテナー全曲の演奏時間総和は257曲で約17時間である(Behind The Sceneが入ったから18時間くらいになってるのかも)。
よって、1回のシャッフルで聴き続ければ中の順番がどうであろうと17時間で終わるが、
シャッフルで60分聴いてリセットしてまた最初からシャッフル→という繰り返しだとこれがどこまで広がるのかは気になる。
これは「60分で聴いてる曲のリスト」の記録を、どれくらい続ければ終わるのかという予想に繋がる話だが、
今までの確率議論とは少し外れるが、今回はそのシミュレーションをしてみたい。
ストレイテナーと確率3(「CLONEをよく耳にする」のは事実なのか?)の続き。
前回は「CLONE」という曲だけに着目したが、これを別の曲にしたときの考察を実施してみる。
手持ちのストレイテナー全257曲の中で、インスト除くと3つある「CLONE」は、
1つ目:平均64曲目、2つ目:平均128曲目、3つ目:平均192曲目
にそれぞれ選択されるということが前回の検証でわかっている。
CLONEは重複度3だったが、重複度が異なる別の曲だとどういう結果になるのか?
を試してみたくなった。
前回の結果を見て疑問に思ったのは、
1つ目:平均64曲目
2つ目:平均128曲目
3つ目:平均192曲目
というように、その差がきれいに64になっていることだった。
CLONEの重複度は3だから、
他の重複度の曲でやるとどうなるのか?実験してみたい。
ちなみにCLONE前提で考えていたので「どの曲か」の判定文字列はソースコードにべた書きしている。
ちょっと直してコンパイルかけるだけだからそれほど苦でもないが
こういう検証をするにあたっては外部から引数等でもらうつくりにした方が良かったなと感じた。(だが直さない)
※ただ、「ストレイテナーと確率3」で使用した検証用プログラムにおける
1試行結果を書き出す処理「(3)シミュレーション メイン処理」は
曲が可変(つまり重複度が可変)になることを想定してListを使用していたので
曲名部分の固定値を変えるだけで対応可能にはなっている
前回↓の続き。
ストレイテナーと確率2
ストレイテナーと確率4
前回の検証では、集計のKEY判定を収録されている曲名の文字列だけで行っていた。
よって、実際には(ほぼ)同じ曲なのに別々の曲として集計されていたり、
一方でオリジナルとアコースティックアレンジで別の曲なのに曲名が同じというだけで同じ曲として集計されていたり、
といった点が若干の心残りとしてあった。
(当時は「面倒くさい」で片づけた)
実例を挙げると(上記記事内でもちょこっと書いてあるが)、
Dear Deadman収録の「Melodic Storm-DEAR EDIT-」はシングルの「Melodic Storm」とほぼ同じだが曲名が異なり、、
TITLE収録の「REBIRTH」はSOFT収録の「REBIRTH」とまったく違うが曲名が一緒。
このため、Melodic Stormの集計範囲からはDEAR EDITは除外されているし、
REBIRTHはオリジナルとアコースティックで全く違うが同じ曲として集計されている。
実際に聴いているときは、曲名ではなくその曲の中身で「どの曲か」を判別しているはずである。
よって、上記の「違い」を加味して、前回行った検証を再実施してみようと思う。
これは、「CLONEをよく聴く気がしてならない」というモヤモヤとしたものが晴れない自分を納得させるためのものである。
⇒この判別を正せば、ひょっとしたらCLONEが選ばれやすさ1位になるんじゃあねーか!?という淡い希望を抱いている
前に書いた記事の詳細を補足する(見返したら自分で良くわからなかったので)。
舞台となるのはDB LINKでつながっている2つの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」は3つあるが、
3つ目の「CLONE」は平均して192曲目までには選ばれる、
というのが前回のシミュレーションでわかった。
同様の考え方が他の楽曲に関しても言えるのであれば、
曲順が進むにつれて「選ばれやすさ」にも変化が起こり、
前半・中盤・後半とでは楽曲別の「選ばれやすさ」も変わってくるのでは?
という疑問から検証をしてみたいと考えた。
例えば1曲目なら257曲の中からランダムに選ぶだけだが、
10曲目、50曲目、100曲目…と進んでいく中では、次に選ぶ曲の選択肢も変化しているはずだから、
楽曲単体(シングルとアルバムで完全に区別をつける)で見れば完全ランダムだとしても、
シングル集計・アルバム集計と、括りを付けて集計していくとその結果も変化するのではないだろうか。
あるいは、リスト内に占めるその集計単位の数(構成比)と一致するのか?
というわけで、その検証をしてみる。