バイアスと戯れる

Rと言語処理と（Rによる言語処理100本ノック終了）

第49回R勉強会＠東京(TokyoR)にて発表しました

R 勉強会 言語処理

　TokyoRの応用セッションにて、Rでいい感じに文字列処理をする{stringr}と{stringi}のパッケージについて、baseの文字列処理と比較して紹介しました。タイトルの「☆」は@kohske先生へのオマージュです。
　本発表スライドは、RPubsに上げたメモ*1を発表用にまとめたものになっております。興味がある方はそちらも併せてご参照ください。

speakerdeck.com

　Rで文字列・言語処理をする際はPythonやRubyなどであらかじめ処理し、その結果をRに読み込ませるというステップを踏まれることが多いですが、{stringr}と{stringi}を活用するとRだけで完結させることも可能です（ひとつの言語ですべて賄おうとする必要があるかと言われればないですが）。
　Rで文字列処理するときはbaseの関数を使わず{stringr}を活用した方が安全ですので（NAの扱いやソート・重複は判定など。詳細はスライドにて）、こちらを推奨していきたいと思います。

　ただし、スライドでも少し触れていますが、Windows環境でSHIFT-JISで書かれたファイルを扱うには、まだまだ厳しいかと思います（R界隈で有名な『Why are you using SJIS問題』。こちらはPythonでもRubyでも変わらない気がしないでも）。

　また、大規模なファイルを処理する場合は、一度にファイルを読み込むのではなく、複数ファイルに分割して処理した方がいいかと（言語処理100本ノックの5章にて、RcppでCaboChaに投げると処理がとても遅い *2）。その際には、本日発表があった@hoxo_m親分の{pforeach}と組み合わせるのがよいでしょう。
　実戦投入についてもご質問がありましたが、私個人で書くときのコードでは、baseの文字列処理を使わないように心がけております。業務でどうこうするには、まずはUnicode正規化やエンコーデイング周り、{stringi}が内部で使っているICUについて知っておく必要がありそうです。まだ闇は深そうですね。

発表資料とRPubsに上げた記事を書いているときに思ったこと

  • 「文字列連結(str_c)」のsep引数とcollapse引数が指定によって変わる結果が覚えにくい
    　「複数の文字列ベクトルをsep引数で交互に連結した文字列を、collapse引数がNULLでなければcollapse引数を間に挟んで連結」という動きでよいのだろうか

  • 「文字列分割(str_split_fixed/str_split)」の使い分け
    　分割数がわかっているときはstr_split_fixedで指定、わからないときはstr_splitという使い分けになりそう

  • 「文字列のパターンマッチ(str_extract/str_match)」の使い分け
    　メモリを逼迫しなければstr_matchを基本的に使うのでよいのではなかろうか

  • 「文字列のパターンの位置(str_locate)」と「文字列の繰り返し(str_dup)」を使うシーンが思い当たらない
    　他の関数と比べて便利な使い道が思い当たらない

  • {stringr}がbaseに取り込まれて欲しい
    baseの文字列処理関数は理由がない限り使わない

発表の所感

　今回の発表は時間内に終わり、枚数も適度に抑えられました。今後も精進したいと思います（淡々と進めたので聞いている方々は退屈だったかも。ひとつ前の@hoxo_mさんの発表がとてもウケが良かったですし）。

*1:RPubs - Stringr-Stringi-base

*2:もしかしたら、C++11の書き方が悪いかも。要確認