生理学実験の実験をやっていると現実世界のいろいろな問題と格闘しながら、どうにかして良い記録を取るという中で、日々工夫を重ねていきます。電極の配置を変えたり、追加したりと言った変更も当然含まれます。しかし、電極の数や配置が変わるということは、記録ファイルのデータ構造・形式が不規則になるということです。
これはコンピューターを使った自動化にとっては脅威でしかありません。ある日のデータでは、そこに脳波の波形があったのに、一週間後のデータではそれが単一ニューロン記録に変わっていた、さらに次の週にはそこに刺激電極と光刺激の信号が加わった、となると、人間にとっては「あー、こういう風に実験の仕方が進歩していったんだなと」比較的容易に変化に追従できたとしても、プログラムから見れば、その都度まったく違うデータ形式を扱っているということで、同じ解析を行うのがとても難しくなります。
前回の記事で書いたように、私の場合、電気生理学データに含まれないその他の情報はすべて巨大なExcelファイルを用意して、その行（縦方向）に記録ファイルとその各チャンネルを当てて、その列（横方向）にそれぞれ異なる変数・パラメータ・測定値等を当てています。
こんな感じです。
| Record | Channel | Date | Animal | Location |
|---|---|---|---|---|
| data001 | chan1 | 2017/07/25 | 1 | Cortex |
| data001 | chan2 | 2017/07/25 | 1 | Thalamus |
| data002 | chan1 | 2017/07/27 | 2 | Cortex |
| data002 | chan2 | 2017/07/27 | 2 | Thalamus |
| ... | ... | ... | ... | ... |
これをファイルの同期・更新の際には、自動で読み込んで必要なデータを抽出することになるのですが、データ形式が途中で変更していて、何行目に何の情報があるのかという予測が外れると当然ながらエラーとなります。そこで、個別の事例ごとに例外処理を書くことになるのですが、このような場当たり的な状況では、本来のコードの中核部分を書くよりも、発生したエラー毎に例外処理のコードを書くのに圧倒的に時間がかかってしまいます。
どんなにマシンが高速になろうが、新しいデータ解析用の言語が登場しようがこの問題は改善しません。恐ろしいですね。
異なる人達の異なる体験
ヒトを対象にデータを取っている生理学者に聞いたところ、もしもそういう事態に陥って、データの形式を変える必要に迫られたら、さっさと実験をやり直すと言っていました。実験が容易にできて、実験一回あたりのコストが低ければ、これは問題にならないということです。しかし、動物実験のデータなど貴重なので、形式変更だからと言ってむざむざ捨てるわけに行きません。
また、この話を理論神経科学者にしてみたところ、最初は難しさの意味がまったく分かってもらえませんでした。詳しく説明して状況を理解してもらった後で言われたのは、理論家はもちろん高度な計算を行ったりするわけですが、データ構造そのものは極力シンプルにするので（当然ですね）、この泥臭い生理学者の悩みを経験したことがないということ。つまり、データ構造の不規則性、複雑性では、生理学者の泥臭いデータは、理論家やモデル屋の人たちが普段触っているような整然としたデータの比ではないらしい、ということです。
同じ話を同じような実験生理学者にしてみると、今度は皆同じような悩みを抱えていることに気付かされます。あまり誰からもこれという解決策を聞いたことがありません。
対処法（アイデア）
思いつきの対処法としては、実験の仕様（コンフィギュレーション、記録条件）を変えるたびに、実験仕様の定義ファイルを作って、ユニークな名前をつけ、データと実験仕様とを明確に関連付けておくというのはどうでしょうか。巨大Excelファイルの一列を使って、たとえば『Config』と名付けて、実験仕様名を保存しておく。どのデータファイルとどのデータファイルが同じ実験データの形式になっているのかを常にユニークな名前で同定できれば、定義ファイルにどういうデータ構造なのか明記されていれば、問題が生じても対処しやすいと思います。
この例では、三回目の実験で電極を増やしてしまったので Configの名前が変わっているというわけです。
| Record | Channel | Date | Location | Animal | Config |
|---|---|---|---|---|---|
| data001 | chan1 | 2017/07/25 | Cortex | 1 | conf001 |
| data001 | chan2 | 2017/07/25 | Thalamus | 1 | conf001 |
| data002 | chan1 | 2017/07/27 | Cortex | 2 | conf001 |
| data002 | chan2 | 2017/07/27 | Thalamus | 2 | conf001 |
| data003 | chan1 | 2017/07/30 | Cortex | 3 | conf002 |
| data003 | chan2 | 2017/07/30 | Thalamus | 3 | conf002 |
| data003 | chan3 | 2017/07/30 | Striatum | 3 | conf002 |
| ... | ... | ... | ... | ... | ... |
こういう風にしておけばよかった、と思いますが、まだ試したことはありません。
データ解析のカノニカル・パイプライン
Live Scriptを使用。探索目的のスクリプトの命名法は、scr20170725_112030_hogehoge.mlxという形式。発表用のスクリプトは、区別できるようにmain1_hogehoge.mlx（Figure 1に対応）という形式。
-
環境設定
- フォルダパス設定、パラメータなど
-
ファイルの同期・更新
- Excelワークシートからのデータ抽出とマージ
- 生理学データの持つ不規則性が障害となる
- 2つのファイルをマージして1つのファイルを出力するときの7つのシナリオ
-
データの解析計算
- 時間のかかる計算処理は結果を保存して次から読み込む
-
parforを使った高速化 waitbarはできるだけ使わない- 特定のデータにアクセスするための仕掛け
-
統計検定
- table型のデータを徹底活用
- グループ化変数 grouping variables（MATLABドキュメンテーション） を最大限利用
- 図の作成
まとめ
実験につきものの記録条件の変更・改良がプログラムを動かす時に自分の首を絞めかねないというお話でした。