設計と分析におけるブロック変数について混乱が続いています。こんにちは、私は JMP Pro 15.2.1 を使用しています。
計画された実験でのブロックについてずっと混乱しています。 特に、本当にブロックしているかどうか。
私の実験では、3 つの 2 レベル (オン/オフ) の関心要素があります。 応答変数はタスクの実行時間です。 2x2x2 階乗を実行したいと考えており、主効果と二元交互作用の重要性をテストすることに興味があります。 私は 24 回の実行、つまり 8 回の治療のうち 3 回の繰り返しを利用しました。
さらに、6 人の異なるオペレーターが実行を実行していると仮定します。 私は演算子効果には興味がありませんが、この変動の原因を説明したいと考えています。 問題を複雑にしているのは、私が制御できない制約により、各オペレーターが「現れ」、異なる実行数 (ランダム化された 24 の実行テーブルの 2 ～ 6 つの実行の間) に割り当てられることです。
次のような方法で実験を行ったとします。
- オペレーター 1 が現れ、たとえば 6 回の実行が可能になりました。 24 の実行テーブルから 6 つのランダムな治療をオペレーター 1 に割り当てました。
- オペレーター 2 が現れ、たとえば 4 回の実行が可能になりました。残りの 18 回の実行から 4 つのランダムな治療をオペレーター 2 に割り当てました。
- 24 回の実行が完了するまで、残りのオペレーターでこの作業を繰り返します。
したがって、これは正確にはブロックされたデザインではありません。 のオペレーターはランダム化に対する制約ではありませんでした。 これはカテゴリ共変量に似ています。 おそらくオペレーターのスキルは異なりますが、私には彼らのスキルを表す定量的な尺度（経験年数やベースラインのパフォーマンステストなど）がありません。
分析を行うときは、単純にオペレーターこの変動の原因を説明するための項 (6 人の演算子は母集団からのサンプルであるため、変量効果として) はどうなるでしょうか? を割り当てますかデザインの役割(JMP列プロパティを使用)オペレーターカラム？ その場合、ブロック役割または共変量役割を割り当てますか? それとも、私の実験のやり方を考えると、それは不適切なのでしょうか？ それとも単に入力するだけですか?オペレーター他の主効果と同様にモデルを考慮し、それ自体には興味がないので単純にその重要性を無視しますか?
BIBDを見るべきですか? そのための JMP モジュールは私の制約に適合しないようでした。
皆さんありがとう。
実験計画法Re: 設計と分析におけるブロック変数について混乱が続いています。実験を計画するときは、演算子は無視します。 あなたが提案したように、共変量のように扱いますが、後で追加します。 [テーブルの作成] をクリックした後、新しい公称データ列として演算子を追加します。 この列を使用して、各実行のオペレーターを記録します。 この列をモデルの項として追加し、ランダム効果属性をこの項に追加します。
これは最適ではありませんが、実用的であり、機能します。 このアプローチにより、メインの実験の設計に集中しながら、演算子間の追加の変動を考慮することができます。
Re: 設計と分析におけるブロック変数について混乱が続いています。ありがとう@Mark_Bailey私は正しい道を進んでいたと思います。 オペレータにデザインの役割モデルに変量効果項として追加すると何か違いが出ますか?
Re: 設計と分析におけるブロック変数について混乱が続いています。DOE 因子の列プロパティは、この場合の演算子の共変量には役に立ちません。
Re: 設計と分析におけるブロック変数について混乱が続いています。私の考えは次のとおりです。
1. あなたの発言には当惑しています。」演算子効果には興味がありませんが、変動の原因を説明したいのです。」 演算子 (ノイズ) を制御できないことは理解していますが、演算子の効果を理解したいと思います。さらに重要なのは、研究内の要因の効果が演算子を変更しても一貫しているかどうかです。
2. おそらく手遅れかもしれませんが、なぜできないのかわかりませんプラン研究に演算子の効果を含める (たとえば、実験で「現れる」ときに基準を満たす特定の演算子のみを使用する)。 実行するには不便で時間がかかるかもしれませんが、「より良い」情報が得られるかもしれません。
3. についての仮説はありますか?なぜ演算子は応答変数の平均または変動に影響を与える可能性がありますか? 具体的には、オペレーターの動作の違い、またはオペレーター間で何が異なるのか? 実際に何が変化しているのかをより具体的に仮説できれば、その効果を実験に組み込むためのより効率的な手段が得られる可能性があります (経験、技術、器用さなど)。 そうであれば、ブロッキング配列または外積配列を効果的に使用できます。
4. 留意すべき点は、ランダム化はバイアスを最小限に抑え、推論を増やし、誤差を定量的に推定するための優れた戦略ですが、ランダム化された誤差は割り当てることができません。
5. あなたの状況では、マークの提案に沿って、演算子という名前の列を作成し、さまざまな演算子をコーディングします。 実用的なグラフ分析 (分散分析と比較) から始めます。 データをプロットするときは、「行」>「色」または「列ごとにマーク」を使用し、演算子の列を選択して興味深いパターンを探します。 オペレータの効果は治療効果と共線的である可能性があることを理解してください。
Re: 設計と分析におけるブロック変数について混乱が続いています。いくつかの回答がありましたが、実験では実際に 5 人のオペレーターで構成されるチームがあったことを明確にさせていただきます。オペレーターはチーム内でネストされており、チーム間で混在することはありません。 各ミッションはチームによって実施されるため、モデルに「チーム」という用語を含めました。
1. はい、オペレーターのチームが変わっても影響する要因の影響 (ある場合) を知りたいです。 しかし、それはランダム効果の迷惑要素です。 私の興味は、実験で観察された因子効果がチームの理論上の母集団に一般化可能であると主張することだけです。
2. このようなオペレーターのスクリーニングは、現時点ではオプションではありません。 ただし、その他の考慮事項については、以下の #5 を参照してください。
3. 一部のゲーマーを他のゲーマーよりも優れているか、または劣っている要因の種類を推測することができます。 しかし、それらのスキルは、数回実行するまで明らかになりません。 #2 で回答したように、彼らのパフォーマンスを事前に上映する余裕はありません。 しかし、サインアップ中に、共変量として定量化できるゲーマー経験 (ゲーム歴の年数など) を参加者から引き出すのは合理的です。 もっと考えてみよう#以下5。
4. コメントなし
5. 各オペレーター (より具体的には、5 人のオペレーターのグループであるチーム) をすでに追跡しました。実験全体を通じて各参加者がいる場合 (私たちはそうではありませんでした)、チーム間でオペレーターを混合して、不良の影響を軽減することができたでしょう。個人チーム内でのパフォーマンス。 重要なことに、私たちはより大きなことを観察していますチーム内応答変数の分散が我々よりも大きいチーム全体で分散。 したがって、モデルに「チーム」という用語を含めても、エラーの管理にはほとんど役に立ちません。「チーム」要素と他の要素の間に相関関係はなく、これは良いことです。 また、チームのスコア (応答変数) がその後の実行 (つまり 3 回目と 4 回目の実行) で改善したという証拠はほとんどありません。 また、より大きな分散は以前の実行に関連するものでもありません。 それにもかかわらず、大量のノイズを伴う 4 回の反復を行うのではなく、学習効果を確実に排除し、記録の実行が最適で、チーム全体でより類似していることを確認するために、トレーニングを 3 回「実行」することができたと思います。パフォーマンス能力。 言いにくい。
