読了:合崎(2015) Rのsupport.CEsパッケージとsurvival::clogit()で選択型コンジョイント分析

合崎英男(2015) Rパッケージsupport.CEsとsurvivalを利用した離散選択実験の実施手順. 北海道大学農經論叢, 70, 1-16.

 離散型コンジョイント分析のRパッケージSupport.CEsの作者ご自身による解説。このたび離散型コンジョイント分析の実験計画についてのメモを作っていて、その都合で目を通した。
 Aizaki(2012 JSS), Aizaki, Nakatani, Sato(2014 書籍)の日本語解説版とのこと。ほんとは本を読むべきなんだけど。

 実験計画のつくりかたは次の通り。Chrzan & Orme(2000)でいうところのmix & match 法だそうである(そうなの?? shiftingじゃなくて??) Support.CEs::rotation.design()で実装されている。例として、3属性、3x3x3水準、9試行、3選択肢としよう。

  1. プロファイル集合を直交配列でつくり、これを選択肢1のプロファイル集合とする。DoE.base::oa.design()で作る由。ってことは、うまくいけば直交配列だけど、単なる完全要因実施計画かもしれないわけね。
  2. 全プロファイルの全属性の水準番号をひとつ上に回転し、これを選択肢2のプロファイル集合とする。同様に選択肢3のプロファイル集合もつくる。
  3. それぞれの集合からひとつづつ非復元抽出し、試行とする。えーと、つまり、各集合の行順をランダマイズして、上から順に試行1, 2, …とするわけね。
  4. 試行内でプロファイルがダブったらやりなおす。

 ちょっとよくわかんなくなったんだけど(著者の先生の説明ではなくて私の理解力の問題です)、仮にstep 1で作られたのが完全要因実施計画だったら、step 2でつくる選択肢2, 3, … 用のプロファイル集合って、単にstep 1でつくったプロファイル集合の行順をランダマイズしたものになる、という理解であっているだろうか?
 もしそうなら、ここで提案されている実験計画の作り方は、cbcTools::cbc_design(n_resp = 1, method = ‘orthogonal’)にかなり近い。違いは次の2点だ。

  • 運良く完全要因実施計画より行数が少ない直交配列が見つかった場合(上の例がそうで、\(L_9(3^4)\)が使える)、cbcToolsは単にその行順を単にランダマイズして選択肢2, 3, … のプロファイル集合とするが、Support.CEsはrotationによって別の直交配列をつくる。この点についてはSupport.CEsのほうが気が利いている気がしますね。もっとも、刺激作成にコストがかかる(実験を通じて提示されるプロファイルの種類数を減らしたい)場合はcbcToolsのほうが都合がよい。
  • Step 1で作られた直交配列なり完全要因実施計画なりの行数が試行数より少ないとき(たいていはそうでしょうね)、挙動が少し違う。たとえば、2属性、3×2水準、4試行, 2選択肢だとしよう。Step 1では6行の完全要因実施計画が作られる。その行番号1,…,6をプロファイル番号と呼ぼう。選択肢1のプロファイル集合も、選択肢2のプロファイル集合も、ともに{1,2,3,4,5,6}だ。Support.CEsは各選択肢について、ここから4試行を非復元抽出するから、各選択肢内でのプロファイルのダブりは生じない。いっぽうcbcToolsは、これを2回ランダム順に並び替えて縦に積み、上から試行1の選択肢1,2, 試行2の選択肢1,2,…として余りを捨てるから、選択肢内でのプロファイルのダブりが生じる(たとえば試行1が(1,2), 2が(3,4), 3が(5,6), 4が(1, 3)ということが生じうる)。うーん、これはまあ、どっちでもいいかな。
  • cbcToolsは試行間重複をチェックしているがSupport.CEsはチェックしていない模様。上の例で、試行1が(1,2), 2が(3,4), 3が(5,6), 4が(2, 1)だということになったとき、cbcToolsではやり直しになるけどSupport.CEsではならない。これはちょっとまずいですね。もっとも、この論文に書いてないだけで、Support.CEsはその辺も上手くやっているのかもしれない。使ってみないとわかんないな。