UA-115498173-1

2019年03月30日

オーギュメントコードと実験計画

先週お話ししたように,ブログ移行の作業中です.Bloggerへのインポートがうまくいかないので,手動で過去の投稿を移しているのですが,この機会に記事を読みなおして適宜修正を入れたりしてます.今だったらこう書かないなというのが結構目に付きますね.これから過去の記事を読まれる方がいらっしゃるならば,あちらで読んでいただく方少なくともがタイプミスは減ってます.

移設先はこちらです.統計的問題解決研究所 https://thinkstatistical.blogspot.com

もうしばらくはあちらでも記事を投稿する予定ですが,やはり面倒なので来週からは更新止めるかもしれません.少なくとも,こちらでは画像を入れたりリンクを貼ったりもしませんので,今後はあちらに行っていただけるとありがたいです.本日の記事でも画像が抜けているのでわかりにくいかもしれませんが,ご容赦ください.

このような事情で過去の記事を読みなおしたりしていますが,「統計的問題解決入門」執筆当時のことが思い出されます.わたしの場合,大学の先生とも違って,執筆には土日をさくしかないのですが,執筆中はいつも鶯の鳴き声が響いていた記憶があります.今も鶯の谷渡りが聞こえているので,ページ数の制限や,外国人の名前を呼び捨てにするかとか,データ引用の著作権のことなどで悩んだり,そもそも書籍を出版するなどというのは無謀だったかもと後悔したことなどがフラッシュバックしています.今になって振り返れば,大変だったけれどセミナーで同じことを繰り返さずに済むようになったのは,その甲斐がありました.先日も「温度は折れ線グラフで書いてはダメだよ」などと話していたら,比例尺度と間隔尺度との違いがわからないというので「p7のコラムを読んでね」と返事したりしてます.

一番の収穫はブラインドタイピングできるようになったことでしょうか.実は,性懲りも無く別の本を執筆しています.「統計的問題解決入門」の執筆ではようやくブラインドタイピングできるようになった頃に脱稿でしたから,今回は前回比およそ1.5倍で執筆中です.脱稿が見えてきたら,またこの場で報告いたします.

さて,「DOEを成功させるためのヒント」の続きですが,今週は前置きが長くなってしまったので,前回の「カスタム計画を使おう」を補足するにとどめます.わたしはカスタム計画一押しで,少なくともイノベーションを目指す技術者にはその他の計画は必要なしという過激派ですが,いくつかの例外はあります.三つあって,その一つが拡張計画です.といっても,特定の計画手法があるわけではなく,計画を拡張するというだけの意味に過ぎません.実験計画メニューの下にある「拡張計画」では,拡張選択として以下の手法が用意されています.


ここで拡張計画といっているのはこの拡張選択の右端にある「拡張計画」です.ちょっとややこしいのでSAS社には言葉を変えてもらいたいですね.そもそも英語では拡張計画はAugment Designなのですが,拡張という訳はJMP日本語版独自のものでしょうか.Augmentは拡張というよりは増強です.アメリカ滞在時にUnited States Marine Band(海兵隊の音楽隊)の奏者にサックスを習っていたので,少々Jazzのコードがわかるのですが,augと添字されるコードがあります.5thが半音上がって根音・長三度・増五度とノート間隔がすべて長3度になるちょっと独特な奇妙な感じがする特殊なコードで,オーギュメントコード(オーグメントとも)と言います.このaugはaugmentを意味するもので,明らかに増加する(半音上がる)ことからのネーミングです.ですので,augment designは拡張計画というよりは増大するというニュアンスを加味して増強計画と訳した方が良いと考えています.

そうでないと,日本語で拡張は範囲の拡大を意味しますから,後付けで設計因子が追加できるのかと思う人が出てきます.(実際にいらっしゃいました.)確かに元がカスタム計画であれば,実験空間の拡張もできますが,設計因子の追加は無理です.実験空間の拡張もせっかく取れているバランスが崩れるので,軽々しく拡張するのは考えものです.拡張計画は交互作用の追加のためと割り切った方が安全です.そういえば,以前「計画を拡張すると手薄になるのではないか」という質問を頂いたこともあります.「拡張とは書いてありますが,実際は増強です.」とこのときはお答えしました.

拡張計画では「実験回数の指定」にいつも悩むのですが,そこはうまく計画の評価を使ってください.実例を挙げて,拡張計画をうまく使って実験数を圧縮する事例なども紹介したいのですが,すいません,時間が来てしまいました.ブログ継続のコツは時間をかけすぎないことなので,ここで締めます.

カスタム計画以外に例外的に使う計画の残り二つについては書けなかったので,また今度お話しします.それではまた.
タグ:JMP
posted by Tad at 19:00| Comment(0) | TrackBack(0) | 講演コンテンツ

2019年03月23日

グラフビルダーの「区間」ゾーン

はじめにご報告しておきたいのですが,近いうちにこのブログを移設しようと思っています.当面はここにも同時掲載していきますが,よろしければ来週からは移設先に行っていただけるとありがたいです.費用をかけるほどのブログでもないので,とりあえず以前使っていて使い方を知っているというだけでBloggerにしました.移設の理由ですが,さくらネットのブログは使いにくいというだけでなく,記事のカテゴリーやタグを泥縄式につけていったので一度リセットしたかったからです.Bloggerにうまくエクスポートできないので,時間ある時に手動で今の記事は移動していきます.それが完了するまでは,こちらとあちらに同じ記事を書いていく予定です.

さて,ここのところ「「DOEを成功させるためのヒント」について書いているのですけれど,飽きてきました.そこで本日は違うことにしたいのですが,何にしようかと考えるに,最近気づいた些細なことを.

先週とあるJMPのセミナーで講師をしたのですが,私はJMP14で受講者はJMP13という環境でした.グラフビルダーのGUIを説明していてJMP14には新たにドロップゾーン(変数をドラッグしてドロップしようとすると色が変わる領域のことです)として「区間」というデータゾーンが右側の一番下(「サイズ」の下)に加わっていたことに気づきました.この役目は言わずもがなですが,何気に便利ですね.例えば,サンプル平均の棒グラフを描いて,そこに標準偏差「SD」のエラーバーを載せたいときは,「SD」をこの「区間」ゾーンにドロップします.

もちろん,グラフビルダーには,グラフ要素のオプション(グレーの開閉ボタンまたはグラフ上で右クリックで出します)に「誤差バー」というのがあるのでそこからSDやSEを選べばこと足ります.この「区間」ゾーンが便利なのは,たまにあるサンプルの統計量だけが与えられているデータのグラフを書く場合です.例えば,最近発表された「World Happiness Report 2019」に添付されているデータはテーブルには「Happiness score」と「Whisker-high」「Whisker-low」という統計量があるだけで,サンプル詳細は不明です.

そこで「Happiness score」を「Y」にドロップしてから,「Happiness score」と「Whisker-high」「Whisker-low」とを「区間」にドロップするとこのようになります.
DraggedImage.e79a7ed84d9d4b5391f00ec2b315a840.png
このとき,ドロップしようとすれば気づくはずですが「区間」ゾーンは例えば,こんなふうに三つのサブゾーンに分かれます.ちょっとわかりにくいですが,青い実線で囲われているのがサブゾーンです.
DraggedImage.ccd877e2b54748fa89af37cf9a027076.png
この図では左下のサブゾーンに「Whisker-high」をドロップしているところで,この操作によって「区間」に二つの変数を設定できます.真ん中のサブゾーンにドロップすると先に入れた変数を上書きしてしまいますので注意が必要です.

この仕様の良いところは,上下限を独立して指定できるので,例えば,下限に「Happiness score」を入れると,このような片側だけのエラーバーを入れることもできます.
DraggedImage.403dd0ce973c48b2b851b55c3b0febf0.png
この片側エラーバーはあまりお勧めはしませんが,医薬関連の論文にはなぜかよくでてきます.因みにこのグラフは参考までに載せましたが,こういうグラフは書いてはいけません.なぜだかはお分かりですね.注記さえしておけば,独自の定義によるエラーバーも載せることができます.例えば「Range」など面白いですかもしれません.あまり見かけないのでしっかり注記してください.

「World Happiness Report 2019」はちょっと気になる報道があったので今原著を読んでいるところです.何かわかったらブログで書こうと思っています.
それではまた.
posted by Tad at 19:00| Comment(0) | TrackBack(0) | JMP

2019年03月16日

カスタム計画を使おう

本日も「DOEを成功させるためのヒント」の続きを書きます.今回のヒントは「カスタム計画を使おう」というとても簡単でものなので,あまり説明する必要はないかもしれません.わたしがこんなことを言うまでもなく,JMPの実験計画メニューはJMP12からだったかJMP13からかは忘れましたが,このようになりました.
112.png
これはJMP14のメニューですが,「カスタム計画」を先頭に,それを補うための「拡張計画」を従えています.区切りが入ったその下には決定的「スクリーニング計画」があり,「古典的な計画」がその下に続きます.下の三つのメニューは「特殊な目的」の「Space Filling計画」を除いては,あまり使うことはありません.「計画の診断」にある「計画の評価」はとても有効な機能ですが,普通にカスタム計画を作ると「計画の評価」はレポートに出力されるので,独立したコマンドとして使う機会はさほど多くないと思います.
ご存知の方も多いと思いますが,カスタム計画はJMPだけの用語であって,一般的には最適計画(Optimal Design)と呼ばれています.Nordström, Kenneth (1999), Statistical Science 14 (2): 174–196 によればGustav Elfvingという統計学者が極地観測において観測回数(実験回数)を最少にすべく考案した手法がもとになったようです.実験回数の圧縮に生命を賭した,まさに生き残るための実験計画だったわけです.わたしたちにとっても実験回数の圧縮は切実な問題ですから,これを使わない手はありません.
とは言っても,医薬系を除く日本の製造業のメーカーでは馴染みがないと思うので,上司や同僚にカスタム計画とは何かということを説明する必要がるかもしれません,そんなときは,数式を並べるのではなく,より具体的に従来の実験計画と異なっている特徴が求められます.それは何かと考える鍵が「古典的な計画」です.この下のサブメニューには「スクリーニング計画」「応答曲面計画」「完全実施要因計画」「配合計画」「タグチ配列」の5つがあります.この中で「配合計画」はちょっと異端で,なぜに「古典的な計画」に押し込まれているのか不思議です.計画の手法というよりは実験の制約に関する計画手法なので「特殊な目的」の下に入れたほうが良いような気もします.事実,配合計画では「最適計画」や「Space Filling」といった(古典的ではない)計画の種類が選べます.改めてその他の4つの計画を眺めると,それらは基本的に直交計画であることがわかります.カスタム計画の特徴を伝える際は,直交計画との比較を念頭に入れるといいです.
それでは,L12,L16,L18等に代表される直交計画とはどういうものかと長所短所を挙げてみると.
● 直交しているので安全な計画が組める
● ツールを必要としない
安全といっても予測に安全という意味ですが,これが最大の長所ですね.JMPユーザーにとってはソフトを必要としないというのは長所にはなりません.
● TAGUCHIのロバスト設計が適用できる(L18)
これは長所といって良いものか悩みますが,要因効果図が正確に描けるということは長所といっても良いかもしれません.
● 計画の選び方,割り付けに知識を要する
● 実験数が比較的多くなる
これらが短所です.これに対し非直交計画であるカスタム計画では,直交計画とは真逆の特徴になります.
● 既存の知見を生かすことで,実験数が圧縮できる
● 拡張計画による戦略的で粘り強い技術活動を支援する
少し飾った表現があざといかもしれませんが,これが長所です.一方,短所は以下のようなものでしょう.
● 直交していないためできた計画の評価が必要
● ツールが必須
● TAGUCHIのロバスト設計の適用不可
安全な計画と判断するには計画の評価が必要ですが,JMPならば(勝手に)実施してくれますし,安全性という意味では,そもそも最適化設計にはいかなる計画を採用しても再現性の確認が必要です.ですから,JMPユーザーであって,品質工学をやるのでもなければこれらは短所とは言えないでしょう.
結論としては,実験数の制約が厳しく,(そのことのデメリットを覚悟した上で)一実験でも減らしたいならばカスタム計画に限ります.更に.わたしがカスタム計画が技術者向けと思うもう一つ理由は,いろいろ覚える必要がないということです.実験計画を勉強することなしに,身軽に実験計画を使って最適化を実施して素早く問題解決に挑むことの意義は大きいと考えています.
カスタム計画以外にも,拡張計画とか決定的スクリーニング計画,あるいはSpace Filling等の有効な計画があり,これらとの使い分けについて,あるいはカスタム計画においても最適化の基準等知っていくべきことはありますので,これらについてはまたいつか書こうと思います.
それではまた.
タグ:問題解決 JMP
posted by Tad at 19:00| Comment(0) | TrackBack(0) | 講演コンテンツ