Rでの単位根検定はadf.test()関数よりCADFtest()関数がいいのでは？

時系列データをあまり扱わないのでまじめに考えてなかったんですが、Rで単位根検定をする場合、拡張ディッキー＝フラー検定（augmented Dickey–Fuller test）を実施してくれるadf.test()という関数があります。
しかしこの関数は、

• 考慮するラグの次数を指定しなかった場合、サンプルサイズ（時系列データの長さ）を基準にして自動選択している
• 定数項もトレンド項も含むパターンしかやってくれない

という制限があり、後者についてはたいていの場合含めといたほうがいいらしいので問題ないとして、前者はよくわからない基準であって*1、本来はAICなどに基づいて選択されたラグ次数を用いたモデルで検定したほうがいいと思われます。実際ラグ次数によって結果がけっこう変わることもあるので、慎重に選んだほうがいいかと思います。

ということで、以下の記事で説明されているように、CADFtestパッケージのCADFtest()関数をつかっとけば簡単でいいんじゃないでしょうか。

定常過程かどうかのチェック(ADF検定)

上の記事だと色々やってて分かりづらいかもしれないので、パッケージの仕様書を見たほうがいいと思いますが、

Package ‘CADFtest’

これを読むと、共変量付きのADF検定ってのもできるらしいです。てうかそもそも，頭の"C"がCovariateのCで、それ用のパッケージみたいですね。
で、一番単純な使い方としては、

#dに時系列データがベクトルで入ってるとする

CADFtest(d, 
   type="trend",   # トレンド項も定数項もあり
   max.lag.y=10,  # ラグの最大次数を自分で適当に指定
   criterion='AIC'  # ラグ次数はAIC基準で選ぶ
)

でいいんじゃないでしょうか（共変量を考えるときは、dを入れている最初の引数にモデル式を記述するとのこと）。
typeのところを"trend"にすると定数項もトレンド項もあり、"drift"にするとトレンド項なし、"none"にするとどっちもなしになるようです。よほどの理論的理由がない限り、両方入れておくのが保守的らしいです。
単純に結果だけ知りたい場合は、上記をprintして出てくるp-valueが0.05を下回っていれば、5%水準で「単位根あり」の帰無仮説を棄却できることになります。0.05より大きければ、単位根過程の疑いありです。

なお、正確に理解してないのですが、CADFtestでラグ0が選択されることがあり、そういう場合は、ADF検定ではなくDF検定に切り替えたほうがよく、adf.test()でk=0としてやればいいようです。（リンク）

詳しい使用例が以下のドキュメントにのってました。
Covariate Augmented Dickey-Fuller Tests with R

間違ってたらごめんなさい。

*1:「このRの自動選択基準はきわめていい加減なので、信じてはいけません」と評している方もいます（リンク）

Rで要素番号の指定の仕方をミスった

　考えてみればそりゃそうか、という感じではあるのですが、またいつかミスりそうなのでメモしておきます。
　たとえば以下のような感じで、startとendの値を変えて適切な期間を取りたいとします。

> v <- c(1961, 1962, 1963, 1964, 1965, 1966, 1967, 1968, 1969, 1970)
> start <- 3
> end <- 5
> v[start:end]
[1] 1963 1964 1965

　それで何かの都合から、startとendの値を少しずらしたいことがあったとします。
　たとえば終了年度を1年早くして、1963年から1964年を取りたくなって、end-1みたいなことをするとミスります。

> v[start:end-1]
[1] 1962 1963 1964

　このように、意図としては(1963, 1964)という出力が欲しかったのに、(1962, 1963, 1964)になってしまっています。
　なんでこうなるかというと、上の書き方だと、start:endの部分でまず(3, 4, 5)というベクトルが生成され、この各要素から1を引くという処理になってしまって(2, 3, 4)になるからですね。
　ちなみに対処としては、start:c(end-1)にしておけば意図どおりになります。

　同様の理屈で、

> v[start+1:end]
[1] 1964 1965 1966 1967 1968

　これは1:endつまり(1, 2, 3, 4, 5)のそれぞれの要素に、start=3を加えるという処理になっています。

> v[start-1:end]
Error in v[start - 1:end] : 
  only 0's may be mixed with negative subscripts

　これはエラーになっていますが、なぜかというと、1:endの部分で(1, 2, 3, 4, 5)という数列が生成され、start=3からそれぞれを引いた数の列になるからです。
　すなわちこの場合、(2, 1, 0, -1, -2)という数列になり、要素番号が適切に指定できなくなります。

Pythonの簡単なコードでメールを自動送信してみる

意外と簡単にできた

　メールを300人ぐらいに発信する必要がありまして、Toに全員入れるわけにはいかないし、BCCで送るのもダサいかなと思って、「1人1人を個別にToに指定して、同じ件名・同じ文面のメールを送る」ってのをPythonでやってみました。*1
　標準モジュールのemailってのとsmtplibってのを使って、50行程度のコードで簡単に送れました。
　１点心残りなのは、後述のとおりFromの欄に日本語の差出人名を表示させるやつが、色々調べたものの結局できませんでした。

用意するもの

　アドレスリストをCSVで用意して、本文はテキストファイルに書いておきました。

コード

　ネットでsmtplibを使ったPythonでのメール送信の解説を探すと、sendmail()というメソッドで送っているものと、send_message()というメソッドで送っているものがあります。sendmail()が基本なのですが、send_message()はそれをより簡単に扱えるようにラップしてくれているような感じらしいです。今回はsend_message()を使いました。

　コードは以下の通りですが、全体としては、

1. モジュールを読み込む
2. 差出人アドレスやメールサーバの認証情報などの設定項目をまとめて書いておく
3. メールサーバに接続する
4. emailモジュールのMIMETextでテキスト形式のメール本体（MIME文書）をつくる
5. MIME文書に、差出人、件名、宛先等の情報を入れていく
6. smtplibのsend_messageでメールを送信する
7. サーバとの接続を終了する

　という流れになっています。

# モジュールの読み込み
import time
import smtplib
from email.mime.text import MIMEText
from email.header import Header
import pandas as pd

# 基本的な設定たち
srv_smtp = 'XXXXXX.XXXXXX.jp'  # SMTPサーバ
srv_port = 587                 # ポート番号
srv_user = 'XXXXXX'            # サーバのユーザ名（ちなみに私が使ってるやつだとメアドがユーザ名）
srv_pw   = 'XXXXXXXX'          # サーバのパスワード
jp_encoding = 'iso-2022-jp'    # 日本語文字エンコーディングの指定
add_sender = 'XXXX@XXXXXX.jp'  # 差出人（自分）アドレスの設定
add_bcc = 'XXXX@XXXXXX.jp'     # BCCの複製を送るアドレス
add_rcp_path = '/XXXXX/XXXXX/address_test.csv'  #アドレス一覧が入ったCSVの置き場
body_path =    '/XXXXX/XXXXX/body_test.txt'     # 本文を書いたテキストファイルの置き場
mail_subject = 'くさめの件につきまして'         # 共通の件名

# 本文ファイルの読み込み
with open(body_path, 'r', encoding='utf-8') as file:
    mail_body = file.read()


# 宛先リスト読み込み
# 元ファイルには名前も入れてるけどとりあえず使わないことにする
add_rcp_df = pd.read_csv(add_rcp_path, encoding='utf-8')  # csvの読み込みはpandasでしかやったことないので…
add_rcp_list = add_rcp_df['Address'].tolist()


# SMTPサーバへの接続
server = smtplib.SMTP(srv_smtp, srv_port)
server.ehlo()
server.starttls()  # TLSでアクセス
server.ehlo()
server.login(srv_user,srv_pw)  # ログイン認証

# 送信を繰り返す
for add in add_rcp_list:
    try:
        msg = MIMEText(mail_body.encode(jp_encoding), 'plain', jp_encoding,)
        msg['From'] = add_sender
        msg['Subject'] = Header(mail_subject, jp_encoding)
        msg['Bcc'] = add_bcc
        msg['To'] = add
        server.send_message(msg)  # 送信する
        time.sleep(3)  # 3秒まつ
    except:
        # なんかあった時用
        print('An error occured when sending a mail to ' + add)
        

# サーバ接続を終了
server.close()

　MIMETextでMIME文書を作って、件名等の情報を入れた後、特定の情報だけ差し替えるというのが上手く行かなかったので、forループでメールを1通1通送る際に、MIME文書の生成自体をまるごとやり直しています。これが適切なのかよく分かってませんがとりあえずメール送信には成功しました。
　あと、メールソフトに送信済みメールが残らないので、記録用にBCCで自分のアドレス宛にメールを飛ばしています。
　1万件とか送るのであれば、受信側のメールサーバにSPAM判定されないように時間を空けて送る必要があるかと思いますが*2、300件ぐらいならべつに全部即時送信してしまっていいような気はします。上記では一応3秒ずつ空けています。

なんか止まってた

　300件の送信中、2回止まりました。
　たぶん回線が不安な環境だったので、ネット接続が切れたんだと思いますｗ
　エラーが出たアドレスのところを確認して、あと一応BCCでコピーを飛ばしていたメールも確認して、未送信の人だけのアドレスリストを作ってやり直しました。
　上記のコードでは、何らかのエラーが出た時の対処はまったく記述していないので、簡単なコードでむやみに大量のメール送信をすると何が起きるかわからんという点には注意が必要かと思います。

日本語文字のエンコード

　エンコーディングのところに関して、参考にしたブログ記事などが一様に、日本語のメールで伝統的に使われているという'iso-2022-jp'を指定していたので、上記コードではその通りにしてますが、↓のページに書かれているように、今はべつにUTF-8でも問題ないようです。
　実際、UTF-8でも自分の持っている幾つかのメールボックスに送ってみましたが、ちゃんと見れました（ただ、iPhoneとMacでしか確認してないので見れて当然なのかもしれません）。
　
Pythonで日本語メールを送る方法をいろいろ試した
　
　受信側の環境にも拠るのかもしれないので、私は念のため伝統的なほうを使いましたが、実際どっちのほうが安全なのかはよく知りません。
　
　

差出人表示を日本語でする方法が分からない

　上記コードで、

add_sender = 'XXXX@XXXXXX.jp'

のところを

add_sender = 'K.Yoshida <XXXX@XXXXXX.jp>'

にすると、受信側のメールソフトで差出人名を「K.Yoshida」として表示してくれたりします。

　それは今回もできたんですが、ここに日本語の名前を入れる方法というのが色々難しく、結局ちゃんとはできませんでした。
　下記のようなページで紹介されているように、

• send_message()ではなくsendmail()で送る
• アドレス部分はそのままに、日本語の差出人名の部分だけエンコードする。その際単に文字列としてではなくHeaderインスタンスとして生成する

　という方法でできるらしいのですが、自分でやってみたところ、受信側サーバによっては受信拒否、一応送れたサーバでも、差出人名のあとに「@」と受信サーバの情報を表す文字列がくっついた状態で表示されてしまい、要するに不正なメールとして判定されたんだと思います。この辺、正式にできるやり方を調べる必要があります。
　Stackoverflow等をみると海外でもウムラウト付きの文字などを表示させようとして苦労している人がいました。

Python3 日本語でメール送信 - textbook
Pythonでメール送信時に送信者に日本語を使用する : fujishinko 雑記帳

[追記]
下記のとおり、成功しました。
Python3でのメール送信時に日本語の差出人名を使う - StatsBeginner: 初学者の統計学習ノート
[/追記]

拡張

　上記のようにとりあえず単純なメールを送れる状態にしておけば、あとは

• アドレスリストから名前を取得して、本文の一行目に「◯◯様」と可変で入れる。
• そもそも本文自体を人に合わせて変える。
• 途中でネット回線が切れたりするのが怖いのでAWS等の仮想マシンから発射する。
• multipartして、base64した添付ファイルをつける

　など、今後いろいろ工夫できるかと思いました。
　ただ、私のような素人が自前のコードでメール送信をすると、なんか事故が起きそう（宛先と添付ファイルが１個ずつズレるとか）なのでなるべくやりたくはないですね。
　
　

関連リンク

mimeTEXTの説明書
https://docs.python.jp/3.3/library/email.mime.html

smtplibの説明書
https://docs.python.jp/3/library/smtplib.html

ここにemailモジュールとsmtplibモジュールを使ってメールを送る際のコード例が載っています。
https://docs.python.jp/3.3/library/email-examples.html

ここに書かれているように、From欄とかnon-ascii文字を使いたければ、Headerモジュールを使ってHeaderインスタンスとして投入する必要があると書いてあります。
https://docs.python.jp/3.3/library/email.header.html

*1:MacのAutomatorでも、group mailっていうアクションを使うとアドレス帳で指定したグループあてに「1人1人をToに指定した別々のメール」として一斉送信ができるけど、冒頭に'Dear Bob,'みたいなgreetingを入れる必要があり、しかもこれが英語仕様しかないので強制的に最後にカンマが入るという、日本人にとっては中途半端な仕様です。

*2:1万件あれば、docomo.ne.jp等に同時に数百から数千通発射することになる

Macでの年賀状作成環境について（2018年版）

　ブログの趣旨と全然違いますが、備忘のためにまとめておこうと思います。
　私は、サボる年もありますが、出す時は年賀状を200人以上に出すので、けっこうな大仕事になっています。
　しかも東京周辺の知り合いが多く、3〜4年たつと半分ぐらいの人が引っ越してしまっている（自分と同年齢から下10年ぐらいまでの知り合いは、結婚によって引っ越すケースも多いので）イメージで、住所録のメンテナンスがけっこう大変です。

宛名職人にサヨウナラ

　昔は、年賀状は「宛名職人」（リンク）というMac用の年賀状ソフトで作成していました。宛名職人の住所録は、iCloudのアドレス帳に登録してある情報をvCardで書き出しておけば、差分を検出してどっちかで上書きするってのができて便利だったんですよね。
　私は一時期、年賀状ソフト、携帯電話、パソコンのメーラーなどに電話帳やアドレス帳が分散しているのが気持ち悪かったので全部統合してiCloudにぶち込んだことがあります。これで一元化されたので、iPhoneでアドレス帳を開くと、年賀状のやり取りがある人については住所も入っているという状態になりました。で、

• 年末年始以外の時期に、誰かが引っ越したことを知った時は、iPhoneかMacでiCloud住所録を上書きする。
• 年末に年賀状を準備する前に、iCloud住所録→宛名職人住所録の方向で上書きする。
• 年賀状を出す。
• 何人かは「あて所に尋ねあたりません」で戻ってきたり、向こうからくる年賀状によって私の認識している住所が異なることが判明する。
• 届いた年賀状を見ながら、宛名職人の住所録画面を見ながら、カタカタ打ち込んで更新する。
• 年賀状シーズンが終わったら、宛名職人住所録→iCloud住所録の方向で上書きする。

　みたいな感じでやっていました。
　ところが宛名職人は、毎年新しいバージョンのソフトを数千円で買わされるんですよね。古いバージョンでも動くときがありますが、Mac OSの新バージョンが毎年のように出るので、古いバージョンだと不具合が出るようになりました。
　しかも、何年前だったか忘れましたが、最新バージョンにしたのにトラブルが起きたことがあり、まぁ自分に原因があったのかも知れませんし詳細は忘れましたが、とにかく自分が安定して使いこなせないようなソフトは使うのをやめようと思って決別しました。

はがきデザインキットは使いこなせなかった

　その後２年ぐらいは、Windows機の筆まめを使ってやっていましたが、今年は「はがきデザインキット」（リンク）を使ってみようと思いました。Mac版があるので。
　郵政関係者に聞いたところ、はがきデザインキットは日本国内で最もたくさん利用されている年賀状ソフトらしいです。たしかに無料でこれだけの機能があれば、有料の筆まめとかを使う必要はあまりない気がします。

　ところが実際にトライしてみると、住所録の読み込みで躓きました。はがきデザインキット専用のcsvフォーマットなるものが配布されているので、それに従ってcsvを作成したのですが、文字コードを色々変えてみても読み込み後に文字化けしたので、４、５回トライして諦めました。

宛名印字はプリントマジックで

　で、結論として今回は、宛名の印字にプリントマジック（リンク）というのを使うと、比較的簡単に作成できました。

　こんな感じの画面で、CSVを読み込む際に、CSVのどのカラムをプリントマジックのどの項目に割り当てるかを選択します。
　ちなみに、元のCSVにはヘッダ行があるのでそれが１行目に表示されてしまっています。「一行目を無視する」をチェックすると消えますが、ヒモ付け作業が終わるまでは出しておいたほうがわかりやすいです。「項目3は姓に紐付ければいいんだな」とか分かるので。

　元の住所データを、どこで区切って保存しておくかというのは、宛名印字界隈では悩ましい問題ですね。そもそも日本の住所の決め方自体もけっこうややこしいので（以前エントリとしてまとめました）、どこで区切るのが正しいかといった定説もない気がします。

　私はもともと、

(1) 都道府県
(2) 市区町村（政令指定都市の場合は行政区まで入れる）
(3) 町・字から住居番号まで
(4) 建物名と部屋番号

　というふうに分けたデータを作っていましたが、「◯◯町１−２−３−４０５」みたいに、マンション名を省略してかつ部屋番号（ここでは４０５）をそのまま続けている住所しか把握していない場合は、(3)に「４０５」まで含めてしまったりしています。
　そもそも数字のところは「丁目」「番地」「号」という３点セットになっているとは限らないので、住居番号と部屋番号の境目は判別がしづらいです。

　で、今回は、プリントマジックでの印刷レイアウトを考えると、

• 都道府県＆市区町村
• 町・字から住居番号まで
• 建物名と部屋番号

　という３項目に分けたCSVを読み込ませると、いい感じでした。
　プリントマジックでは、たとえば項目9〜項目11をすべて「自宅住所」として指定すると、住所録画面ではこの3項目を連結した情報が表示されますが、印刷時にはこの3つを行で分けて印刷してくれます。
　その際、一行の長さをいい感じにするには、上記のような分け方がちょうど良かったです。

　住所録のうち、選択した行だけ印刷することもできるし、印刷するかしないかというデータ項目もあります。
　印刷しない人のデータなんてそもそも必要なの？と思われるかもしれませんが、「普段は出しているけど、今年はこの人から喪中のお知らせが届いたので出さない」みたいなパターンがありますし、こっちから出してないけど向こうからは届いたので年明けに「返事」を出すという場合は、その人たちだけ「印刷する」に設定して印刷するのが良いですね。

　プリンタの設定でハガキを指定すれば、ふつうに綺麗に印刷できました。印刷ソフトによっては、郵便番号の位置がプリンタとの相性で微妙にずれるため、微調整機能がついてたりしますが、今回は相性が良かったのか、何の問題もなく印刷できました。

デザイン面はPower Point

　宛名職人でも筆まめでもはがきデザインキットでもそうですが、テキストや画像を配置する操作に制限が多くてけっこうイライラしますよね。しかも年１回か（暑中見舞いを入れて）２回しか使わないので、UIのクセに習熟することがない。
　「だから全部フォトショで作る」という知り合いもいます。
　しかしフォトショなどの画像処理ソフトも、文章を多めに書く年賀状を作る場合は、テキストをいれる作業でちょっとイライラすると思います。また、文字も全部画像データとして吐き出されるというのはなんか気持ち悪い気もします。クッキリ印字するためには無駄に高解像度にしないといけないのではないか、とか。

　そこで今回は、Power Point(for Mac)で作ることにしましたが、これは大正解でした。写真や図形や文字の配置が自由自在で、とにかく使い慣れたUIなのでイライラが少ない！

• ページ設定で、画面をはがきのサイズにする。
• 写真や文字を配置する。この際、余白を考えずにパワポのページの端まで使う。
• PDFとして保存する（余白のないPDFができる）
• プリンタ（私はエプソンのもの）の設定で、余白3mmのハガキ印刷を指定。

　これでとてもいい感じに印刷できました。PDFなのでテキスト部分を無駄に解像度の高い画像にする必要もなし。

　来年もこのパターンでいくと思います。
　iCloudの住所録と同期するのは、もう色々めんどうなのでやめることにします。年賀状用のCSVを、それはそれとしてメンテナンスしていく所存です。

今更ながら、Rのアンインストール・インストール・初期設定の復習（Macの場合）

備忘のためのメモが必要

　Rのバージョンアップをしようとしたんですが、Macの場合はアップデート用のコマンドが使えないらしいので、アンインストールして新バージョンを再インストールをすることにしました。
　Rのインストール方法なんて解説サイトが山ほどあるのでこの記事をみるメリットはあまりないですが、自分がやることになった時に自分で書いたブログ記事を見直すのがたぶん一番早いので、まとめておくことにします。
　初期設定一式については、新しくパソコンを買った時とかに一通りやり直さなければならない場面もあるかもしれないですし。
　研究室ではみんなSPSSを使ってる（私もSPSSを使い始めた）ので、学生にインストールを教えることは当面なさそうですが、Rの何かのパッケージを使わないとできないことが出てきたら，教える場面もあるかもしれません。

　なお今回の環境としては、OS X SierraでR 3.4.0を使っていたのをアンインストールして、R3.4.2を入れ直しました。

アンインストール

　今回は試しに、関連ファイルを全て削除しようと思いました。が、後述するように、今回「完全アンインストール」を目指したものの、結局「完全」ではなかった模様です。
　ちなみにメジャーアップデートでなければパッケージは残しておいて引き継ぐことができると思いますが、今回は削除しました。

　まず、削除ツールのApp Cleanerを使った場合、消す候補として見つけてくれるのは以下のものでした。

• "/Application/R.app"
• "/var/db/BootCaches/"の下にハッシュ値みたいな長い名前のディレクトリがあって、その中にある"app.org.R-project.R.playlist"（私は長い名前のディレクトリが複数あって両方とも"app..."を含んでいた。）
• "/var/db/receipts/"の中に入っている、R関連の.plistファイルと.bomファイルいくつか。（.pkgでソフトをインストールした際に管理用に生成される、設定ファイルとバイナリ一覧ファイルらしい。）
• "/var/folders/"の下を掘っていったところに"org.R-project.R"というディレクトリがあり、この下に何かグラフィック関係の設定ファイルのようなものがいくつか入っている。

　とりあえず、全部消す。
　その他、自分で探して消すものとしては、以下で良いんじゃないでしょうか。

• "/Library/Frameworks/R.framework"
• "/usr/bin/R"
• "/usr/bin/Rscript"
• "/usr/local/bin/R"
• "~/library/R/"

　バイナリについては、どこ（とどこ）に置かれているかが、人によって違ったりするのかな。
　"~/library/R/"には標準パッケージ以外に自分がインストールしたパッケージが入ってるんですが、ディレクトリの中はバージョンごとに分かれており、これは消さずに残しておけば、Rのマイナーアップデートであればインストール済みパッケージを全部引き継げると思います。今回は消しましたが。

　あとは、Rでデフォルトのworking directoryに設定していた場所に、

• ".Rprofile"
• ".Rapp.history"
• ".RData"
• ".Rhistory"

　があると思うので、消す。
　.Rprofileも、新たにRをインストールするときに日本語表示の設定とかで再利用するでしょうから、残しておくのがいいと思いますが、とりあえず消しました。

　さて、これで全部かなと思ったのですが、じつは再インストールした後にRを起動してFileの「Open Recent（最近使ったファイルを開く）」を触ってみたら、アンインストール済みのRで以前開いたスクリプト等が候補として表示されました。ということは、まだ何かキャッシュ的なもの？を消し切れてないようです。現時点では何なの分かりませんでした、というか調べてないです。
　またそもそも、今回は関連「ファイル」を順に削除していったわけですが、他のアプリケーションやOSが使っている設定ファイル等に書き込まれたR関連の情報は触ってないわけなので、その辺は後の課題とします。
　

再インストールと初期設定

　つぎに改めてRをインストールして初期設定をします。
　なおRを入れる前に、XQuarzの最新版がインストールされてるかは確認が必要です。古かったらアップデートする。
　インストール方法は省きますが、CRANのサイトで配布されている最新のインストーラをダウンロードしてインストールすればいいでしょう。

　インストールが済んだらRを起動して、Preferences（環境設定）で、

• Default CRAN mirrorをJapanに設定（べつにどこ使っても良いといえば良いんでしょうけど）
• "Rapp.history"を読み込むかどうかの設定ができますが、とりあえず読み込むでいい気がします。これは何かというと、たぶん、コンソール上でカーソルキーの上を押したりして過去の入力を辿っていくときに、前回までにRを立ち上げていたときの履歴も辿れる（その時と同じコマンドが打てる）ということかな？と思います。私はあまり使いませんが。
• "Save workspace on exit from R"は私はNOにしてます。計算に膨大な時間がかかるような分析は滅多にしないし、スクリプトをアタマからケツまで保存してれば分析は再現可能で、ワークスペース自体を保存する必要はないので。

　という設定をしました。
　また、Rのコンソールやグラフ中で日本語の文字を表示させることがある場合、その設定が必要になります。（Mac版の）Rで日本語を扱うためにやることは主に２つあって、ロケールの設定と.RProfileの設定です。前者は人によって不要な場合もある思います。

　まずRを起動した時に、

During startup - Warning messages:
1: Setting LC_CTYPE failed, using "C" 
2: Setting LC_COLLATE failed, using "C" 
3: Setting LC_TIME failed, using "C" 
4: Setting LC_MESSAGES failed, using "C" 
5: Setting LC_MONETARY failed, using "C" 
[R.app GUI 1.70 (7434) x86_64-apple-darwin15.6.0]

WARNING: You're using a non-UTF8 locale, therefore only ASCII characters will work.
Please read R for Mac OS X FAQ (see Help) section 9 and adjust your system preferences accordingly.

　というような注意書きが出ている場合、ロケールの設定（posix標準設定の"C"をOSから引き継いでいる？）がUTF-8を使うものになってないということですが、このままだとコンソール上に日本語の文字列を出力することができません（文字コードの羅列になる）ので、設定変更が必要になります。なおロケール（locale）というのは言語と地域にまつわる設定のことです。ローカルの間違いではありませんｗ
　その方法については解説ページ（リンク）がありますが、ターミナルから変更する場合は、

defaults write org.R-project.R force.LANG en_US.UTF-8

　と打ちます。なお、Rのコンソールからsystem()関数で("")の中に同じコマンドを入力することでも変更できます。
　これは具体的には、"~/Library/Preferences/org.R-project.R.plist"というXMLファイルの中の、

<key>force.LANG<key>
<string>■■■■</string>

　という箇所の■■■■に書かれる情報を変更してることになります。
　「en_US.UTF-8」のところは、「ja_JP.UTF-8」にすると、コンソール上の警告文などが日本語になります。
　個人的には、何かエラーが出て原因や解決策を知りたいと思った時、英語の警告文をGoogleで検索したほうが情報が多いので、英語設定にしています。ここを英語設定にしていても、UTF-8になってさえ入れば、コンソールやグラフ上に日本語を表示することは可能です。

　次に、グラフに日本語の文字を出したい場合はこれだけでは足りなくて、定番ですが「.RProfile」（テキストで作成してworking directoryに置いておけば、起動時に読み込まれる）に設定を書き込む必要があります。
　その内容は、参考ページ（リンク）のものを丸ごと拝借してコピペでいけました。この内容は将来、Rの仕様が変わったりすると、修正が必要になるかもしれませんが、とりあえず現行版ではいけました。これの内容をきちんと自分で理解できてないのが気持ち悪いので、後ほど勉強しなければと思っております。
　なお今回、原因がよくわかりませんが、.Rprofileをテキストファイルから作成したらどうもRが起動時に読み込んでくれてない様子だったので、試しにRのコンソールから、

prof <- "
ここにコードをコピペ
"
cat(prof, file=".Rprofile")

　というふうに作成したら行けました。何でかはよくわかりません。前はいけたんですけど。

ブロックチェーンって「付加価値」が期待されてるわけでもなくね？

　久しぶりにブロックチェーンに関する記事を読んだんですが・・・

qiita.com

　「ブロックチェーンが経済のあり方を変える！」的な一部世間の風潮にクギを刺すような論調の記事ですが、金融機関や役所でブロックチェーンの活用に取り組んでいる人たちの話とは少し違うなという気がしたので、気になった点をメモしておきます。
　上のブログの方の言っている内容そのものが間違っているというより、世間でいま騒いでいる人たちと視点がずれていて噛み合ってないような気がしました。
　私が言っている世間とは、丸の内とか霞が関とかで背広を来て歩いているような人たちのことです。
　なお私はブロックチェーンの専門家でも技術者でもなく、素人の印象ベースで書いてます。

コスト削減を話題にしてる人のほうが多くね？

　上の記事ではブロックチェーンの存在意義について、

ブロックチェーン技術が提供する最大の付加価値が公明正大なビジネストランザクション処理の実現にあると考えます。

　とあるのですが、いま産業界でブロックチェーンを話題にしている人たちは、べつに「付加価値」を強調しているわけではないような気がします。
　「ブロックチェーンのおかげで初めて可能になる業務・取引がある」というような話は、ビットコイン流れのベンチャーの人たちはしてるかもしれません。しかしそういうベンチャーのエンジニアを雇って実証実験をしかけている金融機関の人からは、「業務自体は別の仕組みでもできるんだけど、ひょっとしたらブロックチェーンでやったほうが効率的かもしれない」みたいな話をよく聞く感じです。
　ブロックチェーンの最初の応用例であるビットコインは、あの謎の日本人（？）研究者の論文からしてそうであるように、「特定の組織に管理されたくない」みたいなイデオロギーから出発しているので、「管理されずにすむ」という独自の付加価値が実現されていると言えます。しかし最近行われている実証実験等の取り組みのテーマは、どっちかというと「コスト削減」的な話が多くて、「対価の支払いを増やしてもいい」と思えるような新たな付加価値が期待がされているわけでもないように思うんですよね。

　個人的に耳に入ってくる印象レベルの話なので間違ってるかもしれませんが、よく聞くのは、「ある種の業務を実現する上で、従来の中央管理型の処理よりもブロックチェーンを用いた分散型の処理のほうが低コストな場合があるかも」みたいな話です。「かも」に留まるから実証実験程度のものがいくつか行われているだけになっていますし、「場合がある」程度であって、ブロックチェーンが中央管理型の処理を完全に代替するなんていう話をしている人は個人的にはみたことがないですね。

　「ブロックチェーンだからこそ公明正大になる」という言い方は、たぶんビットコインのイメージを引きずっているのだと思いますが、すでにあまりビットコイン的ではないプロジェクトが多いと思うんですよね。
　「パブリックチェーン」と「プライベートチェーン」という区別があって、ビットコインはパブリックでまさにP2Pの理想を体現したような公明正大な仕組みですが、今は特定の企業（あるいは企業集団）が構築する閉じたビジネス範囲内でのブロックチェーン活用、つまり「プライベートチェーン」のプロジェクトがけっこう多い。そりゃ当たり前で、企業はボランティア団体ではないのでパブリックチェーンなんてものを作りたくなるのは一部のエンジニアだけであって、企業目線で見ればプライベートチェーンの方が「我が社にとってメリットあります」というプロジェクトに仕立てやすいわけです。

信用のない主体が取引できるようになる？

　冒頭の記事に、

ブロックチェーン技術の適用に適したビジネスケースは「信用に乏しい主体がビジネストランザクション処理に参加する」ようなケースに他なりません。

　とありました。これも、「ブロックチェーンを使ったからこそ可能になる取引がある」みたいな意味に理解できるのですが、世間的には、「もともと取引は何らかの形で可能なのだが、そのためのコストがブロックチェーンによって下がるかもしれない」という見方の方が強調されてると感じます。
　信用の乏しい主体というのは、ここでは財務基盤が脆弱とかいう意味ではなく、ウソをつくかもしれない主体という意味だと思います（悪意を持って騙すというより、たとえば自社システムの運用が杜撰で、取引の記録がきちんと残されてないとかね）。ブロックチェーンは、過去の取引についてウソを付けなくする仕組みの一つなので。しかし彼らは、ブロックチェーンによって初めて取引に参加できるようになるんですかね？

　そもそも経済的な取引というのは原理的に、相手を信用できない場面が多々あり、何らかの形で「信頼される第三者（Trusted Third Party、TTP）」が取引の仲介プラットフォームを提供することによって成り立っていることが多いです。根本的なところから言えば、中央銀行がおカネを発行しているのもそうだし、人を騙したら警察に捕まって裁きを受けるという司法システムが国によって整備されているというのもそうですね。もう少し具体的なところで言えば、ECサイトや決済サービスなどが、TTPとして取引を仲介してくれることによって、迅速な売買取引が可能になっています。

　たとえば民法でいう契約は、契約の申込みと申込みの承諾によって成立しますが、後で揉めないためにはそれらを記録するものとして契約書を作っておいたほうがいい。何らかの債務の不履行と思われる事態があった時に、「お前、契約したじゃないか」「いや、そんな契約はしてない」みたいな争いが起きることを防ぐこと、つまり後々「ウソを付けない」ようにすることが大事なわけです。
　で、民事訴訟法には「真正な文書の成立」について定めた条項があって、簡単にいえばサインしてあるかハンコが押してあれば、裁判所はそれを本物の文書であると認めるというルールになっています。もちろん細かく言えばもっと色々な要素によって契約システムが成り立っているわけですが、ここで確認したいのは、法律や慣行や司法システムという形の、人が「嘘をつきにくくなる」ようなプラットフォームが、もともと必要とされ、提供されているということです。もちろん、契約書だけではなく、納品や委託作業の完了を確認したことの記録とか、おカネを払ったことの記録になる領収書とかについても、似たようなことがいえます。

　ECでいうと、Amazonでモノを買う時、売り手と買い手の双方は色々な嘘をつくことが考えられます。それらがすべて防止されてるわけではないですが、何かあったらTTPであるAmazonに記録が残っていて、どちらの言ってることが正しいかが証明される。そのことによって、ある程度のウソ防止が可能だからこそ、取引のプラットフォームとして成り立っています。Amazonマーケットプレイスに出品しているお店なんて全然しらないわけで、相手を信用なんてしてないのですが、Amazonが仲介してくれてるし違法行為があったら裁かれるんだからということで、そこまで躊躇せずに取引ができる状態になっています。
　つまりですね、「信用されていない主体が取引に参加できる」ことがブロックチェーンの付加価値だと言われても、それはもともと、様々な形態のTTPによってこれまでも可能になってきたし、そもそも信用できる相手なんて世の中にそうはいないものであって、TTPに頼って取引をするというのが人類の経済活動においては常態であるわけです。その付加価値は、ブロックチェーンによって初めて獲得されるようなものではない。

　ブロックチェーンの場合は、ネットワークの全体が分散的にTTPと同じような役割を果たしている*1感じなわけですが、関心はそのほうが効率的なのかどうかという点にあるのだと思います。
　たとえば取引に参加している人たち同士の契約（双方の意思表示）の記録を、中央集権的なサーバで行うことにした場合、記録はそこにしかないわけなので、24時間365日確実にアクセスできることが求められるかもしれない。すると、システムの稼働を止めないために多大なコストがかけられることになります。また、そのサーバの提供元が不正をしたり、処理に間違いがあったりしては話にならないので、厳格な運用と監視の体制が求められます。
　一方ブロックチェーンの場合、方式は色々あるんでしょうけど、たとえば本人が電子署名を打って記録を作成し、ネットワークに参加している全ノードにばらまくことになります。そして何らかのコンセンサスプロトコルによって、その記録が正しいことの確認がされ、全ノードがそれを記録していきます。このことによってウソがつけなくなるわけですが、中央にめちゃめちゃ厳重に管理されているシステムがあるわけでもなく、またネットワーク全体で情報を共有しているので、一部のノードが停止したとしてもシステム全体が落ちるわけではない。

　どっちの方式でも、「ウソをつきにくくする」（否認防止）という価値を提供している点では同じです。もたらされる基本的な付加価値は同じ*2。
　で、どっちが効率的なのかは場合によると考えられ、ひょっとしたらブロックチェーンのほうが効率的なケースもあるかもしれないからということで、いろいろ実証が行われているのだと思います。
　たとえば、順序を守って処理しなければならないとか、即時に処理をしなければならないといったことが多い場合、中央の巨大システムにデータを集めてから処理したほうが合理的かも知れませんが、そのへんがある程度ゆるくていいのであれば、中央に厳格な運用体制を敷くよりも、しょぼいコンピュータをネットワーク化して分散的に処理する方式で十分かもしれない。即時性や順序性を犠牲にしていいのであれば、取引参加者のコンピュータが太い回線でつながっている必要もなくなるので、通信コストも削減できるかもしれない。
　実際ビットコインは、取引の記録が正しいものとして承認されるのにある程度時間がかかりますが、これは要するに、「特定の組織に管理されたくない」というP2Pイデオロギーの信念を実現するために、即時性を犠牲にしてるわけですね。

　IoTが進展すると、何兆台というデバイスがネットワーク化されてくる（と言われている）わけですが、大量の低スペックなコンピュータが低スペックな回線でつながっている状態だと、中央にデータを集めて処理してまた返すみたいなやり方は成り立たなくなるから、当事者デバイス間（P2Pで）でいったんやりとりを完了させて先に進み、少し時間差を持って記録の正しさが確定していくようなブロックチェーン的なアーキテクチャのほうが向いてるだろう、みたいな話も聞いたことがあります。　

どういう視点で捉えておけば良いか

　先日会社で、スマートコントラクトにブロックチェーンの仕組みが登場する意味が分からないと言っている人がいたのですが、何で分からなくなったかといえば「ブロックチェーンだからこそ可能になる取引・業務がある」という話だと思ってしまったからです。実際はそうじゃなくて、取引や業務を可能にするシステム構成として、ブロックチェーンが他の方式よりも効率的となる（かもしれない）ようなケースもある（かもしれない）という話なわけですよね。
　とりわけ、言った言わないで揉めることがないように「正しい記録」を保持し続けなければならないという点に着目し、そのためのコストが論点なのだと理解すると、その点だけが重要なわけではないにしても、最近騒いでいる人たちが何を騒いでいるのかがよくイメージできる気がします。

　冒頭で引用した記事の視点がズレている気がすると先ほど書きましたが、もう少し正確にいうと、たしかに「ブロックチェーンの仕組みだからこそ可能になる取引や業務」があるという前提でイノベーションだ何だと煽っている人は多いので、そういう人に対しては冒頭の記事のようなツッコミを入れることは適切なのだと思います。ビットコインの印象が強烈だったので、なんか新たな経済原理が登場したみたいに思っちゃってる人はそれなりにいると思うんですよね。個人的には、ビットコインの仕組みには感心したので、本当に「新たな経済原理」が登場するまで突き詰められれば面白いなとは思います。
　しかし一方で、「もともと可能だった取引や業務のうち、ある種のケースでは、ブロックチェーン方式のほうが効率的に取り扱える」みたいな話をしている人もたくさんいます。冒頭の記事はそういう方向性の議論が視野に入っておらず、ひたすら「新しい価値が生まれるのか否か」を論じている（ちょっと生まれると主張している）ので、私が聞いたブロックチェーン界隈の話とはズレていると感じた次第です。

　先ほども言及した「パブリックチェーン」と「プライベートチェーン」の区別で言えば、冒頭の記事が論じているのはもっぱらパブリックの方だと思いますが、いま金融機関とかが取り組んでるのはどっちかというとプライベートなチェーンの方が多いと思います。ガチのエンジニアの人は、ビットコイン的なオープンでパブリックなシステムを構築するのを夢としているかもしれませんが。
　まぁ「どっちが多いか」を争っても仕方ないのですが、少なくとも、プライベートなブロックチェーンの取り組みがいくつも存在しているのは事実です。プライベートなブロックチェーンにおいては、当たり前ですが、「特定の組織に管理されたくない」みたいなビットコイン的理念はもはや全く関係なくなって、単に業務上の処理を記録していくための方式として効率が良いかどうかの話になります。

　なお私が述べてるのは、最近ブロックチェーン活用を検討している産業界や政府の人たちが何を話題にしているかという話なので、視野は狭いと思います。技術者の世界ではもっと色々幅のある議論がなされているのだろうと想像してます。
　あと、私は専門家ではないので、ブロックチェーンが有望なのかどうか、どういう場合に有望なのか、実際のところは判断できません。「世間で言われているのはこういうことではないですか」と述べているだけですので、悪しからず。

追記

　ブコメで、

ブロックチェーンは分散*合意形成*が肝で、単に分散化による耐障害性や投機実行なら他の方法より明らかに不利ってイメージだったんだけど、用語の指す範囲が微妙にずれてて噛み合ってないのかなあ。

　というコメントがありましたが、まさにそこがズレてきた点でもあると思います。
　金融機関でブロックチェーンやってる人の話をきいていて、「そうか、なるほど、プライベートチェーンの取組みをやってるんだな。いやまてよ、プライベートだったらもはや、合意形成プロトコルは必要なくね・・・？」と思って私も混乱しました。
　特定の企業（企業集団）が構築する、自社業務システムや自社サービス内に閉じたブロックチェーンネットワークなら、ネットワーク内で不正が起きることを防ぐみたいなことは必要なくなり、ビットコインが実現したある種の美しいコンセンサスモデルは、必要なくなる場合があります。
　で、そのコンセンサスモデルが美しいからこそブロックチェーンに関心を持ったのに、「プライベートだからそれは要りませーん」と言われると、なんかブロックチェーンの魅力が半分以上失われたような気持になってしまいますよね。

　今も、ビットコインのようなオープンな仮想通貨システムを夢見て会社を立ち上げたようなエンジニアの人たちは、パブリックチェーンの方にこだわりを持っていると思いますし、世間的にもブロックチェーンと言えばビットコインみたいなイメージがまだあるので、そのへんでズレが起きていると思います。

*1:Trusted Third Partyという言い方だとイメージと違うとは言える。果たしている役割が同じという意味。

*2:まぁ同じとまで言うとある意味言い過ぎなのはわかってる。

Pythonメモ: Pandasで文字列検索をループするとかなり遅かった

　前回のエントリで、Pandasのデータフレームを文字列で検索すると遅かったと書いたんですが、実際に検索の方法を変えるとどれぐらい違うのかを計測してみました。
　結論から言えば、辞書型に変換してから検索したらだいぶ速くなったのですが、それが凄いというよりは、Pandasの基本がまだ分かってないということかなと思いました。こうやると速いとか遅いとかいう記事はいろいろあるみたいなのでまた勉強したいと思います。

　一応、前回のエントリでやった方法を確認のため比較することとして、PN Tableに載っている単語をランダムに1万個選んだ上で、1個1個についてPN値を選択して取ってくるという処理の時間を測ります。
　Pandas内での工夫についてはよくしらないので、Pandasではない形で検索した場合と比べました。
　時間を図る方法は単純に、処理の直前と直後に時刻を取得して引き算するだけにしました。

　まずパターン1では、単純にPN Tableを読み込んだPandasのデータフレームで、単語の列を検索してヒットした行のPN値を取ってきます。
　次にパターン2では、単語の列とPN値の列をそれぞれリストにしておいて、先に単語のリストを検索してインデックス番号を取得し、そのインデックスでPN値のリストから値を取得します。
　最後にパターン3では、単語の列をリストにしたものと、PN値の列をリストにしたものを結合した辞書（dict型）を作っておき、この辞書をキーで検索してPN値を取得します。
　なお、PN Tableの行数は55125行です。

import pandas as pd
import random
import time

# PN Tableを読み込み（パスは適当に）
pn_df = pd.read_csv('dictionary/PN_Table/pn_ja.dic.txt',\
                    sep=':',
                    encoding='utf-8',
                    names=('Word','Reading','POS', 'PN')
                   )

# PN Tableに載っている単語を10000個抽出
word_list = list(pn_df['Word'])               # 語のリスト
searchlist = random.sample(word_list, 10000)  # 探す単語をランダムに決める


# --- パターン1：pandasで純粋に検索 --- #
start_time = time.time()          ### ▼時間計測▼ ###
pns1 = []
for w in searchlist:
    pn = pn_df.loc[pn_df.Word == w, 'PN']
    if len(pn) == 1:
        pns1.append(float(pn))
    else:
        pns1.append(0.0)
print(time.time() - start_time)   ### ▲時間計測▲ ###

# --- パターン2：リストにしてインデックスで検索 --- #
start_time = time.time()          ### ▼時間計測▼ ###
word_list = list(pn_df['Word'])               # 語のリスト
pn_list = list(pn_df['PN'])                   # PN値のリスト
pns2 = []
for w in searchlist:
    if w in word_list:
        ix = word_list.index(w)  # 先にインデックスを取得
        pn = float(pn_list[ix])  # 同じインデックスでPNリストにアクセス
    else:
        pn = 0.0
    pns2.append(pn)
print(time.time() - start_time)   ### ▲時間計測▲ ###

# --- パターン3：辞書にしてキーで検索 --- #
start_time = time.time()          ### ▼時間計測▼ ###
pn_list = list(pn_df['PN'])                   # PN値のリスト
pn_dict = dict(zip(word_list, pn_list))  # さっきのリストと合体して辞書に
pn3 =[]
for w in searchlist:
    if w in pn_dict:
        pn3.append(float(pn_dict[w]))
    else:
        pn3.append(0.0)
print(time.time() - start_time)   ### ▲時間計測▲ ###

　それぞれの時間をみてみると、

# パターン1
>>> 38.16759991645813

# パターン2
>>> 15.531062126159668

# パターン3
>>> 1.524580955505371

　となりました。何回かやってみたけどだいたい似たようなもんでした。
　辞書型に変えてから検索すると、このテストの処理で25倍速ということになりました。
　これが、昨日のエントリで行ったツイートの解析処理だと、色々ループしていることもあって、1万3000ツイートの解析を行った時間でいうと200倍速ぐらいになったわけです。

　そもそもPandasではない形にしてしまっているので無理矢理感があり、もっと勉強しないとなと思います。そもそもデータフレームに対してループで処理するのって適切なんですかね。whereなどSQLライクな関数で取ってくるべき？
　ただまぁ、とりあえず昨日やった処理のどの部分で時間がかかっているかを特定し、そこだけ方法を変えることで全体の処理が圧倒的に早まるという、目先の目的は達成されたのでよかったです。