範疇と構成要素をしっかりと区別すること
範疇
範疇またはカテゴリーとは，このようなものだ。
フルーツという範疇に，バナナ，りんご，みかん，なし，もも…がある。
個物の性質に応じて分類されているものだ。
構成要素
構成要素は，このようなものだ。
車の構成要素は，エンジン，タイヤ，ボディー，ブレーキ…などである。
車が車であるような，その成り立ちを決める一部分のこと。人工物なら，部品といっても通るようなものだ。
範疇と構成要素は，全く異なるものだ。
外国語教育研究における構成概念
「語彙知識には，形式の知識，意味の知識，そして使用の知識がある」
→ 私は理論についてはまったく素人でよくわからないが，おそらくこれは構成要素を示している。
「文法知識には，明示的知識と暗示的知識がある」
→ 私は理論についてはまったく素人でよくわからないが，おそらくこれは範疇を示している。
「動機づけには，道具的動機づけと統合的動機づけがある」
→ 私は理論についてはまったく素人でよくわからないが，おそらくこれは範疇を示している。
非常に紛らわしい。よく混同しているような用例も見る。というか，わたしが理論面についての知識をもたないからかもしらないけど，どちらかわからないことが非常に多い。範疇なのか構成要素なのかを明確に言明してほしい。
ChromebookにLubuntuを入れてしまいAtomに引きこもろうと思ったが…やっぱEmacs！
繰り返される「勝手な」Windows Updateの波に本当に嫌気がさしている。
別にこちらの会社に限った話じゃないけど，いつの間にか，コンピュータは人が命令したことを盲目にする道具じゃなくて，人に先回りしてなにかして，承諾を得るというようなスタイルでひとと関わる地位に上がっていたようだ。私はまだPCっていうのは私の相棒でもパーソナルアシスタントでもなくて計算機だと思いたい。
ある意味，パターナリズムということばの意味を深く考えさせられる。そうか，「コンピュータのことなんかどうせわからない私だから，コンピュータのことなんかどうせわからない私の命令を待つのじゃなくて，コンピュータが私をいいように導いてくれるのか」なんて。だから，「だから，私がコンピュータに命令を出すのでなくて，コンピュータのいうことに従うべきなのか」なんて。
そんなため息をつきながら，Macを使えばいいじゃないかと思って開いてみても，数分もしたらなんかコレジャナイ感に苛まれる。吸血鬼が銀に触れたら火傷するように，私はこのアルミの筐体によって身を焦がす。
Ubuntu系のOSは，ここ10年くらいのつきあいだ。Ubuntu，特にLXDE環境のLubuntuだけにしたい，などといってもそうはいかないときも多い。パターナリズムに怯えながらも結局，Windowsが入っているマシンを触る。だからといってWindowsを開いてもどうせVirtualBoxで仮想的にLubuntuを開いたりする。困ったもんだ。Lubuntuみたいな軽いデスクトップ環境だと，ほとんどの市場に出回るWindows機ではオーバースペックになる。仮想環境のメモリやストレージの割当てを何故かできるだけ少なくして，どれだけカツカツにするかで楽しむようになる。「やばい！領域が少なくて，apt installできない！」みたいなのがいい。…ビョーキだ。
病身の末，唐突に思い立った。いつだって唐突が一番だ。私を救ってくれると期待していたラズパイを，仕事用に使うのはやはりキツいものがあった。ラズパイ，ごめん。でも，それよりはマシだけど，私の身を焦がさない程度に低スペックで，非力で，しかし製品として気が利いているChromebookはどうかと。なによりもWindowsがプレインストールされていない。非力で，そしてWindowsが入っていない。なんて素晴らしい。
日本市場のChromebookはどれも似たりよったりだけど，ASUSさんのChromebook flip c101pa，英語キーボード版をポチった。eMMcで16gb，RAM 4gb，CPUはARM，10インチ，900g。4万程度。タブレットみたいな値段だ。いいじゃないの。とても安い。1kgを切ると軽い感ある。いろいろと変形合体みたいなギミックになっているのは，はっきりいってなんの意味もないのけど，おっさんには嬉しいものだ。それに，むかし愛したSharpのMebius Muramasaにそっくりじゃないか。あのバカみたいな薄さと非力さ。いいぞう，可愛いぞう。
で，ChromeOSには限界がありそうなので，好みのLubuntuを入れる。これはかなりやられていることのよう。
参考にしたのは，こちらのサイトさま。
要はChromeOSから仮想化機能でいれるわけだ。買ったそのときからすぐにデベロッパーモードに入ったら，すげえビープ音とか鳴らすもんでびっくりしたけど，まあ上のリンク先のとおりにしたら，現在もなんの問題もなく導入できる。もちろん，クリーンインストールもできないことはないらしいのだけど，ちょっと設定がめんどいらしい。
ちょっと自分用のメモだけど，terminalからbashに入った段階で，
sudo sh ~/Downloads/crouton -r list
とすると，ディストリビューションのリストがでるので確認したほうがいい。現在は18.04のbionicが最新で，LTSなのでしばらくはこれでいいかな。
追記：…と思ってbionicやったのだけど，現在は18.04のbionicはうまく対応ができていないみたいで，実際に色々問題があった。無理やりやったら解決するだろうけど，手間なので結局その前のLTSであるxenial，つまり16.04で入れたほうが絶対にいい。xenialのサポートは2021まで。もしかしたらtrustyとかのほうがいいかもしれないくらい。
この仮想環境実行中に，ChromeOSとLubuntuはキーボードショートカットキーですぐに切り替えられるみたいだ。便利ね。
ChromeOSも話題になるだけあって，なかなか興味深い。特にGooglePlayに対応しているので，Androidアプリが動く。いいじゃないの。
で，Lubuntuのほうにいつもの通りAtomを入れて，いろいろAtomに連携させればいい。
…などと思ったのだけど，重大な問題を考えていなかった。この筐体，ASUS Chromebook Flip C101PAはARMアーキテクチャだった。調べた限りでは，Atom（エディタ，ややこしい）はこれにまだ対応していない。しまったー。
それに数日使ってみたら，どうもLXDEはそんなに安定してないようで，挙動が結構怪しい。xfce環境のほうが安定しているようだ。最近のGNOMEは正直よくわからないし，ましてやUnityなんて重いしおしゃれだしおしゃれだしおしゃれだし，なんていうか身を焦がすデスクトップ環境の代表だ。
それに，なんと調べたら，まだβ版なんだけど，最近のChromeOSはネイティブでLinuxモードというのを起動できるようになったみたい。この筐体は対応している。
Linuxモードをオンにすると，普通に端末が開いて，aptなどが使えるので，RやEmacsなどをいれてみたら見事動いた。残念ながら，このモードだと日本語対応がまだしっかりとはできないみたいだけど（たとえばEmacs-mozcが入らない），EmacsにESS入れてRを動かしたり，EmacsからMarkdown書いたり，TeXを書いたりといろいろできるので，ま，これでいっか，というような感じ。
Emacsは久しぶりで，自分なんか初心者ともいえない低レベルだけど，Emacsにまたひきこもろう。…というわけで，どうせAtomが入れられないならEmacsするしかないわけで，croutonを使っていれたLXDE環境は一度Powerwashして，LinuxモードからEmacs開くことにした。
というかChromeOSいいね。Android環境とLinux環境が共存している。まあ，もとがそもそも同じようなもんだからだけど。いずれにせよ，これでwineとかしたらWindowsアプリにも動くのがありそうだし，とっても楽しそう。
brmsパッケージでカーブフィッティング
計量言語学のMenzerath-Altmann法則をbrmsで。
（a）
s<-1:5 m<-c(3.1,2.53,2.29,2.12,2.09) dat <- data.frame(s, m) my.prior <- prior(normal(0,3), nlpar = a) + prior(normal(0,1), nlpar = b) + prior(normal(0,1), nlpar = c) fit <- brm(bf(m ~ (a*s^-b)*exp(1)^(-c*s), a + b + c ~ 1, nl = TRUE), data = dat, prior = my.prior, save_all_pars=T) summary(fit)
これ，データポイントが少ないから，事前分布の設定がすげえ問題だよね。
適当に，
- a ~ Normal(0,3)
- b ~ Normal(0,1)
- c ~ Normal(0,1)
とかにした。実際に-1とか1とかの値を取ることがほとんどないbやcはともかく，このaの設定は恣意的といわざるをえないけど。
ちなみに，より簡単な，
（a）
とベイズ因子やWAICで比べてみるとか。
my.prior <- prior(normal(0,3), nlpar = a) + prior(normal(0,1), nlpar = b) fit2 <- brm(bf(m ~ (a*s^-b), a + b ~ 1, nl = TRUE), data = dat, prior = my.prior, save_all_pars=T) summary(fit2)
bayes_factor(fit,fit2) waic(fit, fit2)
fitがfit2より高かったけど…微妙。
AtomからRを使うための設定（Ubuntu系OS）
お気に入りのエディタからなにがなんでも出たくないという病気。
ここ3年はAtom推しなので，今回はAtomからRを使用する環境を作る。
環境は，Lubuntu 18.04 LTS。
でも別にこのOSがなにか特別なわけじゃない。
これまでAtomからRを使うときは，Atomのパッケージである，
- language-r
- autocomplete-r
- build-rscript
などといったものを使っていた。
詳しくは，こちらの記事の通りに。
というか，buildがめんどくさくて，もうterminalをペインに開いて打っていたけど。
でも最近，Atomでrboxというパッケージができたらしい。
これはちょっと便利そうじゃないのー。
基本的な方針としては，
というような手順。Jupyterを経由するという発想。
ま，そのままJupyterを使ってもいいんだけど，個人的にAtomでやりたい。
さて，順番にコードを書いていく。
コンソールからRを入れる
sudo apt-get install r-base-core
Jupyterを入れる
sudo apt-get install jupyter
Atomを入れる
sudo add-apt-repository ppa:webupd8team/atom sudo apt-get update sudo apt-get install atom
IRKernelのための準備
sudo apt-get install libzmq3-dev libcurl4-openssl1.dev libssl-dev
（なんかココ変だな，Rのdevtoolsはcurlがないと入らないのだけど，curlは依存関係があるようだ。もしだめだったら,libcurl3とかを先にいれないとだめかも。で，libcurl-openssl1.0-devを最後に入れるのかな？）
RからIRKernel関連を入れる
install.packages(c('crayon', 'pbdZMQ', 'devtools')) devtools::install_github(paste0('IRkernel/', c('repr', 'IRdisplay', 'IRkernel'))) library(IRkernel) IRkernel::installspec()
これでJupyterとは対応されるはず。
jupyter-notebook
と打って，ブラウザ上からNewを開いて，Rが追加されていることを確認。
あとは，Atom上で以下のパッケージを入れる
- rbox
- hydrogen
- atom-beautify
- termination
これでOKなはず。
ひとに統計相談をするための8つの基本的なTips
その1：データや資料を必ず用意する
統計を得意とするひとであっても，実際のデータやそれに関する資料などが，手元に全くない状態において，（しばしば不正確で非専門的ないい方による）文字や音声だけによる情報で正確に相談の意図を把握することは簡単ではないと思う。データや関連する資料をメールで事前に送ったり，面会する際は印刷して参照できるようにするほうが効率的だ。統計に関する参考書や自分の研究に関する先行研究もよい資料となる。
その2：できればデータを取得した後でなくて，事前に相談をする
ほとんどの場合がそうだが，有意差がでなかった，思うような結果にならなかった，ということについて「統計分析にその原因がある」と一意的にみなし，本来あった研究仮説と整合性がなくなるようなレベルで，モデルや分析法を変えたりするように統計相談をするひとがいる。これはほとんどの場合，被相談者にとって心持ちのよいものではない。実験・調査の事前段階でその計画について相談するほうが大抵は優れた研究につながる。特に研究仮説の書き直し（HARKing）につながるとみて，場合によっては相談自体をお断りされる方もいると聞いた。
その3：質問をできるだけ具体的に細かく分ける
たいていのことはそうなのだが，「大丈夫か」とか「問題ないか」とか「適切か」といった抽象的で曖昧な聞き方をするとあまりよい回答は得られない。たとえば，この計画は大丈夫か？というよりは，「標本サイズ決定の仕方を知りたい」とか「効果量はどの指標を使うべきか？」といった具体的な質問をリストアップするほうがよい。もっとも非効率的なのは「どうしたらいいですか？」だ。これはほとんどまともな返答をもらえない。相談を受ける方にとって，「こうするんだけど適切か」と聞かれたら「厳密には文句がない統計など絶対にない」というだろうし，その程度は非常に曖昧なものになってしまう。
その4：対価に当たる部分についてどのように考えるかを知っておく
相談を受ける側が対価を求めるわけではなくても，その行動にはそれなりにコストが発生しているわけで，それをどうするかは人による。まったく贈答品やお土産の類を受け取らない，論文等の謝辞などもすべて辞退するというタイプのひともいれば，遠慮なく受け取るひともいるし，ある程度以上であれば謝辞や著者権が正当だと思う方もいる。非常に難しい問題なので，事前に対価について相談を受けるひととスッキリしておく方がよい。たとえば，私が相談を受けるときは，対価にあたるものはできるだけ受け取らないようにしているし，謝辞なども辞退する方針でいる。高級なお菓子とかが食べたいからやっているわけではないし，謝辞などに勝手に書かれるのは非常に困る。「自分の勉強のためになりますので…」といって対価を拒むひとが相対的に多いと思う。しかし，だからといっていつでも無対価で頼むとひとによっては失礼になるかもしれない。
その5：自分の理解を超える分析を提案されたらそれを伝える
ときに相談をすると，「そういう問題のときは，こういう新しい分析がありますよ」という提案がある場合がある。そういうとき，その提案された手法を自分がしっかりと理解し，ある程度は著者として責任を持てるようにしなければならない。たとえば査読コメントでその分析について詳しく書くようにいわれたときに，書けないというのではよくない。相談を受けるほうからしてみれば，相談をする方が適切に理解しているか，または今後理解するかを見分けるのが難しいので，自分から「それはできそうにありません」としっかりと伝えるべきだ。まったく責任を自分で持てない場合，著者に入れるというのもひとつの考え方だと思う。
その6：エディター，査読者，指導教官などとの争いに巻き込まないようにする
これらのひとと，相談を受けるひとの方針が対立したとき，普通は相談を受けるひとはなんの責任も負うことができない。たとえば，ある分析をして，エディターがそれではだめだといったけど，「これは問題ないですよね？！」みたいにひとに相談をするのはよくない。けっして代理の喧嘩を頼んではいけない。特に学位論文に関わる際には，仮に指導教官よりも統計面に強いひとに相談したとしても，それが学位論文を審査する人にとって好ましい分析であるかはわからない。
その7：最終的な主張を伝えない
「この研究では，こういうことを主張するために…」というようなことを明確に伝えると，結論ありきの分析につながってしまいかねない。相談を受けるひとが忖度して，かなりQRPに近いことを提案してくるかもしれない。よくある話だけど，ある程度，統計をするひとにとって，有意差を無理矢理つくることは難しくない。非常に難しい問題だが，できれば統計相談の際も，結論を先取りするような態度を示していないか，慎重にありたいものだ。
その8：面会よりもメールにする
面会する場合よりも，文面の方が一般的に質の高いやりとりができる。面会時間よりもはるかに短いあいだで，はるかに質の高い返答をメールで送ることができるかもしれない。たいていは相談を受ける方も，書籍やネットなどでなにかを調べたり，なにかで実際に計算したりするので，ただ面と向かってしゃべっている面会よりは，そういった作業ができるようなメールのほうがよい。多分，メールでは失礼だ，とかお菓子渡したい，というように考えられる方が多いと思うが，そういうのはまったく別の機会でよい。行動の強化を図って即時に強化子たるお菓子を与えなければならないとか，そういうふうに考えない。
気軽に「説明」とはもういわない
説明
あいも変わらず，不勉強ゆえに，よく考えずに軽々しく，説明などという難しいことばを何度も使ってきたものだが（幸いなことにあまり自分の論文や原稿には使用例が見当たらなかったが），他人の使用はどうであれ，私はこの説明ということばを軽々しく使わないことを，死んだ愛犬のジョンに誓った。私が知る限り，少なくともこのことばは，かなりの頻度をもって，健全なコミュニケーションを妨げる。
演繹のこと
説明の科学的定義ともいったりするらしい。一般法則から個別の事象を導くことなど。これは，もっとひろく論理学的にいえば演繹のことだ。
妥当な推論であるところの「A（条件，または仮定）ならばB（帰結，または結論）である」とAが真であるということから，Bが真であると導くわけだ。
人間の会話を例にすると，「どうしてご飯を食べたの？」という疑問に対して，「だってお腹が空いていたんだ」と答えるのは，質問者と回答者の中で，「お腹が空いていれば（条件），ご飯を食べる（帰結）」を妥当な推論として先んじて共有した上で，回答者しか知らぬ条件「お腹が空いている（いた）」が真であることを回答者に知らせ，演繹によってすでに得られた帰結を再確認することだ。
つまり，議論に先んじて得られた帰結と，未だ共有されていない条件の下で，条件を伝え，帰結が演繹によって再確認できることを示す。
心理的帰結のこと
説明の心理学的定義ともいったりするらしい。この定義において説明とは，帰結主義的に，人間の主観および内観において，納得した，理解したという心的状態をもたらすこと，といった具合だ。たとえば，数理モデルで完璧な予測と制御ができる状態でも，それは説明したとはいわないというひともいるし，数式を読む人にとっては数式によって心理学的に納得したと感じるかもしれないし，自然言語でなにかのメタファーを使わなければ納得したと感じないひともいる。大概の場合，なんらかのメタファーと後述するアブダクションによって，納得したと感じるひとが多い。ある研究について，頻繁に「直観に合う」とか「面白い」とか「興味深い」という形容をされる研究者にとって，大概説明とはこの心理的帰結のことだ。草薙がこういうタイプの研究者を悪くいっている，と皺を寄せる方もいるかもしれないが，ここのいい方に他意はない。ただ，そういう方もいる，という記述を与えているだけだ。
アブダクションのこと
パースのアブダクションを論理のひとつとして認めるひともいるし，すくなくともこれが文字通り仮説形成という役割で，我々の研究においてものすごく重要であることは誰も疑わないと思う。しかし，くだらないかもしれないが，もちろん，アブダクションは演繹ではない。
アブダクションは，所与の帰結Bと，A→Bを妥当な推論とみなすことによってAについて推論することだ。もちろん，これはA⇔Bでなければ正しいという保証がない。ご飯を食べたという帰結と，「お腹が空いているとご飯を食べる」が妥当な論理であるとしたうえで，「お腹が空いていたのだろう」と推論することだ。
アブダクションがだめとはいわないが，これは演繹による確認という意味の説明ではない。アブダクションは，数理モデリングではとてつもなく重要で，尤度とかベイズ推定という根幹をなす考え方なんだけど，もっともらしいということを説明とはいわない。
心（mind）一般について私が受け入れない理由はこれだ。私は一般に，（専門用語としての）心は行動からアブダクションされたものだと考えている。たとえば，英会話場面における発話数が少ないという帰結と，スピーキング不安が高ければ，英会話場面における発話数が少ないという（どこから来たかわからない）デカルト的な論理によって，（心としての）スピーキング不安が高いという条件をアブダクションしている。これは少なくとも演繹的な説明の科学的定義に沿うものではない。仮説形成であるとしても，心が見えないばっかりに，このアブダクションされた仮定や条件を直接的に調べる方法はありえない。
予測と統御
最近では，実データの予測と統御がある社会的文脈と歴史の上である程度可能であるという事実を説明と呼ぶという態度も見られる。私自身は，心理的帰結を説明に積極的に含めるならば，別にこれを説明とみなすこともまったくやぶさかではない考えなのだが，コミュニケーションを妨げるひとつ原因であると感じるようになった。*1
で，どうするか
演繹の場合は演繹，アブダクションの場合はアブダクション，予測と制御，そして心理学的帰結をそれぞれいいわける必要があると痛感している。以下のような使い方をする。
- 結果は，論理Xと仮定Yによって演繹的に導かれる
- この言明は，あるひとにとって，心理学的帰結としての説明をもたらす可能性がある（または，広くいってこの言明は効用をもたらす可能性がある）
- 本論文は，観測されたXと論理YによってZという仮説を立てた
- この数理モデルから得られる予測値は，観測データの優れた近似になった
ここまでのまとめ
これまでの「もういわない」は以下の通り。
- 測定する
- 客観的
- 説明
…なので必然的に私は，これからの研究実践において，「客観的な方法でなにかを測定して，事象やその背景にあるメカニズムを説明する」ことはない。
*1:モデリングという考えについて話すときに，毎回「それは説明ではない」とか「それは予測ができるだけで意味がない」というコメントをいただく。何度も，ほぼ必ずといっていいほどこういったお叱りを受けるので，対応テンプレートを用意した。まず，前もって，説明とはいわないことだ。大概は，モデリングによる予測と制御によって，個人および集団の効用を高めることを目標とするといっておけばよい。事実まったくそのように考えているし，個人の心理的帰結としての説明を受け入れるならば，これを説明といわない境界線について考え始めなければならなくなるから。次に，予測ができないが納得する説明と，先生はなぜか納得はされないが完全な予測ができる説明では，どちらが経済学的な意味での成果になりますか？と聞き返すことだ。最後に，先生がおっしゃる説明や意味とはなんですか？と聞き返すことだ。大概これで嫌な顔をされるが会話は終わる
RでABAB計画のグラフ
応用行動分析（ABA）とかで行われるABABデザイン（外国語教育研究では単一事例分析として知られる）の結果について可視化するグラフを描く必要がある。行動系の論文でよくみるこんなやつ。
えっと，ここではABAB計画（baseline - treatment - baseline - treatment）で，反応回数を均等に5セッションずつ記録したとしよう。なので全20セッションとする。
これだとこんなふうに描くといいかな。
#データ例 a1<-c(2,1,4,2,3) b1<-c(7,8,8,7,8) a2<-c(2,1,3,2,3) b2<-c(8,7,6,7,5) #作図例 plot(1:5, a1, type="b", xlim=c(1,20), ylim=c(0,10), cex=2, pch=20, xlab="Sessions", ylab="Number of Responses", axis=F) axis(1,1:20) lines(6:10,b1,type="b",cex=2,pch=20) lines(11:15,a2,type="b",cex=2,pch=20) lines(16:20,b2,type="b",cex=2,pch=20) abline(v=c(5,10,15)+.5,lty=2) text(3,10,"Baseline",cex=1.2) text(8,10,"Treatment",cex=1.2) text(13,10,"Baseline",cex=1.2) text(18,10,"Treatment",cex=1.2)
よし。
