2018年12月12日水曜日

PayPayのキャンペーン、1万円×10件と10万円×1件はどちらが得か

入門編的な確率の問題。

電子決済サービスのPayPayが、2018年末に「100億円あげちゃうキャンペーン」というのをやっている。決済1回ごとに抽選を行い、当選したら決済金額相当(最大10万円まで)を丸々ポイントバックするというものだ。

たとえばこれで買い物をする場合、同じ10万円分の決済を
  • 『10万円まとめて決済する』のと
  • 『1万円ずつ10回に分けて決済する』のと
どちらが得と言えるだろうか?という話。(明日の講義でそのまま出そうかな)

当選確率は加入者のステータスによって変わるが(ワイモバやSBのユーザーだと確率が上がるとか、まあそういうことね)、とりあえず標準の「40回に1回の確率」=0.025をベースに考えよう。別にここが0.05でも0.1でも、この後の議論に本質的には影響しない。

平均で比べる

一番分かりやすいのは、「平均いくらのポイントがもらえるか」の比較だろう。

10万円まとめて決済する場合、確率$0.025$で当選した場合10万円が得られ、確率$(1-0.025)=0.975$で0円が得られる。すなわちポイントバック額の平均は
\[ 100000\times 0.025 + 0\times (1-0.025) = 2500 \]
ということで平均2500円。
これに対して、1万円ずつ10回に分けた場合は1回のポイントバック額平均が
\[ 10000\times 0.025 + 0 \times (1-0.025) = 250 \]
となり、これを10回行うので平均はやはり2500円となる。つまり平均額に違いはない

当たる確率・外れる確率で比べる

「外れる」といっても、これは何回かの抽選を行って「一度も当たらない」という意味である。
10万円まとめての決済だと、抽選の機会は一度きりなので、当たる確率は$0.025$, 外れる確率は$(1-0.025)=0.975$。
これに対して、1万円ずつ10回決済する場合は抽選が10回行われる。これで一度も当たらない確率は
\[(1-0.025)^{10} = 0.7763\ldots\]
である。言い換えれば最低1回は当たる(場合によっては2回3回…10回当たるかも)確率は0.22程度であり、「当たった!」という喜びを得られる確率は高くなる

当たった時のポイントバック額で比べる

確率が高いとは言え、これは当たった際のポイントバック額を犠牲にして当たる悦びを追っているとも言える。10万円まとめての決済だと、確率0.025で当たった時は当然10万円が得られる。
これに対して、1万円ずつ10回の決済だと、10回のうちちょうど1回当たる確率はおおよそ0.2だが、ポイントバックは1万円だけ。10回のうち2回当たる確率は0.023で、1回だけの抽選で当たる確率より既に低いのである。しかもその時に得られるポイントバックは2万円。10回やって10回当たる確率は小数点のうしろに0が16個も付くほどの小さな値であり、10万円が得られる可能性はほぼ無いと言える。

分散という指標

つまるところ、10万円の決済を1回でやる場合と、1万円の決済を10回やる場合の違いは

  • 確率は低いが、当たった時のポイントバックが大きい方がいいと考えるか
  • ポイントバックの額は犠牲にして、当たって欲しいと考えるか
という違いであり、平均としては変わらない。これをうまく表現するための指標が、分散である。
この例でいくと、分散とは当たった時/外れた時のポイントバック額と、平均額とのずれがどの程度大きく生じるかを表している。分散が大きければ損も得も大きく、小さい場合は損得それぞれ平均に近いところで小さく振れる。分散には2乗の計算が含まれるので、元の数値(ここでは円という通貨)に単位を合わせるため、標準偏差(分散の平方根を取った値)を用いることも多い。

具体的には、10万円の決済1回の場合の標準偏差$\sigma$は
\begin{align*}
\sigma & = \sqrt{(100000-2500)^2 \times 0.025 + (0 - 2500)^2 \times (1-0.025)} \\
& = 15612.5\end{align*}
であるのに対して、1万円の決済10回の場合は
\begin{align*}
\sigma & = \sqrt{10 \times ((10000-250)^2 \times 0.025 + (0 - 250)^2 \times (1-0.025))} \\
& = 4937.1\end{align*}
となり、決済を10回に分ける方が標準偏差が小さい(=分散も小さい)ことが分かる。これが、損得の振れ幅が小さくなっているという意味である。

2018年6月28日木曜日

CentOS7でOpenVPNを動かしてみた件

はいはい備忘録備忘録。

1. インストール

以下、全部管理者権限で。
標準ではパッケージが用意されていないが、ソースから作るのも(アップデートとかを考えた際に)めんどいのでEPELを追加する。
# yum install epel-release
続いてopenvpnと、お手軽な証明書生成スクリプトのeasyrsaをインストールする
# yum install openvpn easy-rsa

2. 証明書と鍵の生成

 この辺のページこの辺のページを参考にしつつ作業。要するにまず認証局(CA)を作り、それをベースにサーバ側の証明書と秘密鍵の生成、という順序でやる。EPELパッケージでのeasyrsaスクリプトは/usr/share/easy-rsa//の下にある。
まず初期化。
/usr/share/easy-rsa/3/easyrsa init-pki
続いてCAの作成。
 # /usr/share/easy-rsa/3/easyrsa build-ca
鍵を利用するためのパスフレーズを2回入力し、Common Name(適当な名前)を入力する。このとき、カレントディレクトリにpkiというディレクトリが作成され、pki/ca.crt(証明書)とpki/private/ca.key(秘密鍵)が出来る。
次にサーバ証明書と鍵のペアを生成。
# /usr/share/easy-rsa/3/easyrsa build-server-full server nopass
 pki/issued/server.crt(証明書)とpki/private/server.key(鍵)が生成される。
(これは順不同)DHパラメータの生成。ちょっと時間がかかる。
# /usr/share/easy-rsa/3/easyrsa gen-dh
pki/dh.pemが生成される。まとめると、以下のファイルがカレントディレクトリ下に出来たことになるので、これらをまとめて/etc/openvpn/にコピる(設定ファイルで絶対パスを指定できるので、適当なディレクトリに置いても構わない)。
pki/ca.crt
pki/private/ca.key
pki/issued/server.crt
pki/private/server.key
pki/dh.pem

3. OpenVPNサーバの設定

設定ファイルは標準で/etc/openvpn/server.confだが、とりあえずサンプルをコピって修正してもよい。
# cp /usr/share/doc/openvpn-/sample/sample-config-files/server.conf /etc/openvpn/
以下の設定が有効になっていることを確認する。(行頭にシャープまたはセミコロンがあるとコメントアウトされた状態なので、有効にしたい場合は外す)
proto udp #tcpだと遅くなる
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
topology subnet
push "route 192.168.0.0 255.255.255.0" #VPN経由でアクセスしたいサブネット
tls-auth /etc/openvpn/ta.key 0
user nobody
group nobody
で、tls-authで用いるta.keyを生成する。
# openvpn --genkey --secret /etc/openvpn/ta.key
標準ではポート1194を使うので、開けておく。
# firewall-cmd --add-service=openvpn --zone=public --permanent

2018年6月13日水曜日

VMware ESXiにLet's Encryptで作成した証明書をぶっこむ件

手順を忘れないように記録。たとえばVMware ESXi  6.5がvmw.example.comで動いている前提。

  1. 手元のホスト(certbotが動けば何でもいい)でDNS-01 challenge validationを使った証明書取得を行う。以下では$PWD/certにcertbotの各種生成ファイルがあると仮定する。
  2. ESXiでSSHを有効にする
    • ナビゲータ→ホスト→アクション→サービス→SSHの有効化
  3. 取得した秘密鍵(privkey.pem)、証明書(cert.pem)、中間証明書(fullchain.pem)をESXiに転送。
    • scp cert/config/live/vmw.example.com/{privkey,cert,fullchain}.pem root@vmw.example.com:
  4. SSHでESXiにリモートログインし、ファイルをコピー。一応丁寧にバックアップを取っておく。
    • cd /etc/vmware/ssl
    • cp rui.key rui.key.old && mv /privkey.pem rui.key
    • cp rui.crt rui.crt.old && mv /cert.pem rui.crt
    • cp castore.pem castore.pem.old && mv /fullchain.pem castore.pem
  5. Web UIの再起動。
    • /etc/init.d/hostd restart
    • /etc/init.d/vpxa restart
    • 一部サイトではservice.sh restartで良いとも書いてあるが、VMwareのサポートページではやってくれるな(仮想マシンが全部死ぬ)とあるので、稼働状態ではやらない。
  6. 不正な証明書などの警告が出なくなることを確認。

2017年10月22日日曜日

nasneのファイル共有領域がマウントできなくなったので設定を変えた件

Ubuntuからnasneの共有フォルダーをマウントしていたのだが、Ubuntu 17.10で同じ設定のままマウントしようとすると "mount error(112): Host is down"と出てマウントに失敗する。

ということでいろいろ調べたところ、mount.cifsが使用するSMBプロトコルがデフォルトでSMBv1では無くなった様子。man mount.cifsするとまだv1がデフォルトであるように書いてあるのだが、実際vers=1.0を指定しないと上記のエラー、vers=1.0を指定するとマウントできるようになるので、デフォルトでSMBv2以上を使うようになったのだろう。

というわけで、/etc/fstabの最下行に次のような(1行で書く)設定を追加すればOK。IPアドレスはnasneの設定済みIPアドレスに、/mntは自分の環境でのマウントポイントに、hogeは自分のアカウントに置き換える。
//192.168.0.2/share1   /mnt  cifs  guest,uid=hoge,gid=hoge,nounix,dir_mode=0755,file_mode=0644,vers=1.0
nounixを指定することで、CIFSのUnix拡張(ファイルモードや所有者)を拾わないようになる。これとdir_mode,file_modeなどを組み合わせて所定のファイルモードでの参照が可能になる。実行ファイルは置けなくなるが、まあいいんじゃないだろうか。

それよりSMBv1の脆弱性がいろいろ問題になっており、mount.cifsがSMBv1を標準にしなくなったのもそういう事情があるのだろう。Windows10もFall Creators UpdateをクリーンインストールするとSMBv1サポートが入らない(アップグレードだと残る)らしいので、できればv1を使わない方向に進みたいところ。ソニーが果たしてそこまで手間をかけてnasneのファームウェア更新をしてくるかどうか…?

2017年3月31日金曜日

日程が操作されている可能性はどの程度か?という話

「99.999%」JリーグがFC東京のために日程を操作したことが判明鹿島アントラーズデータブログ)というブログ記事がFC東京サポーター界隈でちょっと話題になっている。
今は昔の1999年、J2参入初年度にナビスコカップ(現在のルヴァンカップ)準決勝で鹿島と対戦し国立で引き分けた時、「あの鹿島に引き分けられるとは!」と感動した身としては、この記事を見て隔世の感を覚え、東京も鹿島から妬まれるほどの立場になったのだなあと感慨にふける次第である。

が、本ブログはTech Memorandumであって科学技術の話をすべきであろう(そうだったか?)。

元記事の論旨

当該記事においては、AFCチャンピオンズリーグ(ACL)に出場するJリーグ4チームが特に他国強豪クラブと対戦する直前または直後の週末に、東京との対戦が組まれているという点に疑問を呈している。詳しく書くと、以下の日程で4チームすべてACLの直前または直後に東京との対戦がある、ということである。(当該記事で掲載された日程表に、ACLの対戦カードには引用者が[ACL]と付記し、またJリーグの部分には節を付記した)。
鹿島アントラーズ
2/21 蔚山現代[ACL]→2/25FC東京(第1節)
4/22磐田(第8節)→4/26蔚山現代[ACL] →4/30鳥栖(第9節)
浦和レッズ
3/10甲府(第3節)→3/15上海上港[ACL](→3/19G大阪(第4節))
4/7仙台(第6節)→4/11上海上港[ACL]→4/16FC東京(第7節)
川崎フロンターレ
3/10柏(第3節)→3/14広州恒大[ACL]→3/18FC東京(第4節)
4/8甲府(第6節)→4/12広州恒大[ACL]→4/16札幌(第7節)
ガンバ大阪
3/11FC東京(第3節)→3/15江蘇舜天[ACL](→3/19浦和(第4節))
4/7広島(第6節)→4/11江蘇舜天[ACL]→4/16C大阪(第7節)

さて、当該記事ではそのような日程が「たまたま」組まれる確率として
(3/14)×(3/14)×(4/14)×(3/14)=0.001%
という計算式を示している。式の導出過程は示されていないが、たとえば鹿島については強豪蔚山との対戦前後にリーグ戦が第1・8・9節の3日分あり、そこで対戦し得るACL不参加チーム14のうち東京が入る確率(=3/14)、ということを表しているのであろうと推察される。

元記事の計算における問題点

まず、左辺の計算結果は0.00281...となり、パーセント表記すると0.281%である。この辺はケアレスミスであろうが、タイトルからして違ってきてしまう(上記結果に基づけば操作された確率は99.999%ではなく99.72%である)。
第2に、浦和とG大阪の直接対決をなぜか組み合わせから除外しているが、この対戦は事前に決まっているわけではないので、ここに東京が入る可能性も考慮すべきだし、逆に他の節でも直接対決が起こる可能性を考慮すべきである(14チームでなく17チームで見る)。これであれば、例えば鹿島と東京の対戦が第1・8・9節のいずれかになる確率は3/17となり、それ自体は確率として正しいと言える。
しかし、たとえ個別の対戦について3/14でなく3/17という確率で求めたとしても、上記の計算式はそれを単純に乗じており、すなわち4チームとの対戦をすべて「独立」であるものとして扱っているのでまずい。実際には、たとえば3/11のJリーグ第3節にG大阪と対戦するのであれば、同じ第3節に浦和や川崎と対戦する可能性はなくなるので、そのようなパターンを除外する必要があるのだが、独立を仮定すると同日に対戦することを許してしまう。このように、単純な掛け算で求めた結果は正しいとは言えない。

正しい確率の求め方

ではどのように求めるべきか。ACLグループリーグはJリーグの前半戦(第1~17節)に行われるので、鹿島・浦和・川崎・G大阪のそれぞれに(重複しないよう)1~17から4つの数字を選んで割り振ることを考える。これで東京がACL出場4チームと「第何節に対戦するか」のリストができるが、これは高校で扱う順列に相当し、そのパターンは
17P4=17×16×15×14=57120通り
である。このようなパターンのうち、鹿島と1・8・9節のいずれかで対戦し、かつ浦和・川崎・G大阪の3チームすべてと3・4・8・9節のいずれかで対戦するパターンは
4P3=3×(4×3×2)=72通り
である。したがって、FC東京の対戦順序が全くランダムに決められる場合、「たまたま」元記事が指摘するような対戦日程になる確率は
72/57120=0.00126...(パーセント表記だと0.126%)
と考えるのが妥当ではないだろうか。

おまけ:0.126%って高いの?低いの?

さて、本稿では確率計算に関する誤りの指摘と、正しいと思われる数値の導出を行った。蛇足ではあるが、「じゃあ0.126%ってのはほとんどありえない確率なの?」という点についても書いておこう。サイコロを投げて1の目が4回続けて出る確率は0.00077...=0.077%で、これよりは大きい。コインを投げて10回連続表になる確率が0.00098...=0.098%で、これよりも大きい。つまり、「サイコロで1の目が4回も連続するなんてありえない!このサイコロは細工されている!」と考える人にとっては、大きいとは言え近い確率なのでまあ操作の可能性を疑う余地もあるのかなあ、と思うが、これはまた別項にて。

2016年9月24日土曜日

ベトナムでプリペイドSIMを使ってみた件

カンボジアを発ち、アンコールエアのプロペラ機でホーチミンへ。ベトナムでのSIMカード購入も備忘録的に書く。

事前に調べた限り、ベトナムの携帯キャリアは基本どれも国営で、2016年5月段階でLTEは試験段階、通信品質にそれほど差はないらしい。1GBあたり10万ドン(約500円)と見積もっておけば、それほどぼられた感じにはならないだろうという結論に至った。

ホーチミンのタンソンニャット国際空港には昼過ぎの到着。日本からの便は夜に着くことが多く、ネット情報によれば空港のSIM販売店が閉まっていることがままあるらしいが、今回は余裕。到着ゲートを抜けてすぐの両替店でまず最低限(SIM費用+市内までのタクシー運賃+夕食代程度)の円をベトナムドンに換金。

到着ゲートを背に左方向(タクシー乗り場に近づく向き)に進むと、観光客用SIMの販売店がいくつかある。空いている店に聞いたら3GB30万ドンの奴しかないよーんと言われたので、他の旅行客もたむろする隣の店へ。こちらは何か知らないけど「unlimitedで20万ドン」と言われ、いや無制限とかありえないでしょーと思いつつ相場的には1.5GB+超過後は速度制限だろうと想像。滞在は4日弱なので、これで十分ということでSIMを購入。カンボジアのSIMを抜いて店のお兄さんにセットアップをお願いしたら、さっくりと開通。

3Gとは言えそれほどのストレスは無く、通信が途切れたのはメコン川クルーズのときくらい。さすがにあそこは「海ですか!?」と言いたくなるくらい川幅が広く、電波が届かないところがあっても仕方があるまい。それでも中州のレストランではしっかり電波が拾えた。

これで海外プリペイドSIMの実績は3ヶ国。パッケージツアーは日程や訪問地を事前に念入りに調べないと購入やチャージが難しいが(イタリアの例)。こういう状況では、成田でWi-Fiルータを借りる方が確実ということはある。他方、フリーツアーで「英語が通じる」都市部や著名な観光地にいくのであれば、SIMロック解除された(あるいはSIMフリーの)携帯を準備して現地でプリペイドSIMを購入するのがコスト面でメリット大と言える。

カンボジアでプリペイドSIMを使ってみた件

昨年のイタリア(準備編実践編使用感)に続き、カンボジア・ベトナムと周る機会があったので備忘録的に。

イタリア渡航前にSIMロック解除したXperia Z2を今回も活用。イタリアの時はパッケージツアーだったために購入のタイミングが極めて限られていたのに対して、今回は飛行機・宿とも自分で確保してじっくり見て回る旅なので、選択肢はかなり多い。ということで、渡航前にいろいろ検索して調べると、どうやら今はSmartというキャリアが良いらしいという結論に。結局Smartにはならなかったのだが。

カンボジアのシェムリアップ空港ではホテルにピックアップを依頼していたため、ここでは買わずトゥクトゥクで市街地に突入。シェムリアップは世界的な観光地なので、英語は大抵の店で通じる。ナイトマーケットのドラッグストアにSmartのラベルがあったので入って聞いてみたところ、「Cellcardしかない」と言われた。Cellcardも一応4G/LTEサービスを開始しているらしいし、他の店を探すのも面倒なのでCellcardのSIMを購入。1ケ月有効のデータSIMが3.5GB分で5米ドル。ちなみにカンボジアでは米ドル紙幣が通用し、小さい釣銭だけが現地通貨リエルで返ってくる。

SIMを差し替えたところ、最初はなかなか電波を取りにいかなかったのだが、2回ほど再起動したところで電波を掴んで無事開通。シェムリアップの市街地ではLTEも来ているようで、快適な通信ができていた。尤もホテルにはWi-Fiが完備されていたので、ホテルの中ではほとんど出番無し。

アンコール遺跡群の観光においては、Cellcardの電波は少々厳しかったように思う(他のキャリアを試してないのでわからんけど)。アンコールワットバイヨンのようなメジャースポットであれば3G通信ができるが、それでも巨岩の陰に入ると電波が途切れる。プレア・カーンプレ・ループあたりになると2G接続中心になり速度的にもストレスが強く、またかなり場所を選ぶようになる。

アンコール遺跡群の中でも特に離れた場所にあるバンテアイ・スレイ(東洋のモナリザで有名)までは市街地からトゥクトゥクで小一時間かかるが、道のり途中では電波が途切れることが多かった。一方で、道路わきにはSmartの看板を掲げた店がしばしば見られ、やっぱり時間をかけてもSmartを買えばよかったなあとちょっと後悔。

英語配列のノートPCで日本語配列設定にしちゃった時に、アンダースコアを入力するTips

US配列のLG gram SuperSlimを購入した。で、Windowsの初期セットアップを始めたところ、最初に選択できるキー配列はMicrosoft IME(まあ要するに日本語配列)だけ。で、その後に「追加のキー配列」を選択できるのだが、後でやればいいやと思ってスルーしてしま...