分割が悪いですか?次のような表があるとします。
| カテゴリ |
アイテム |
レベル |
| A |
1 |
デルタ |
| A |
2 |
フォックストロット |
| A |
3 |
ホテル |
| B |
1 |
ジュリエット |
| B |
3 |
五 |
カテゴリー=B、アイテム=2 が欠落していることに注意してください。
このテーブルを、「分割基準」 = カテゴリ、「分割列」 = レベル、および「すべて保持」で「分割」しようとすると、次の結果が返されます。
| アイテム |
A |
B |
| 1 |
デルタ |
ジュリエット |
| 2 |
フォックストロット |
五 |
| 3 |
ホテル |
|
新しく分割されたテーブルでは、Item=2、Category=B が「lima」と表示されていますが、これは誤りです。そのセルは空白で、「lima」は Item=3、Category=B の下にある必要があります。
これはユーザーエラーでしょうか、それとも JMP のバグでしょうか?
データのブレンドとクリーンアップRe: スタッキング不良？こんにちは@BHarris さん、グループ内のアイテムを使ってみてください。期待通りの結果になるはずです。
最高、
Re: スタッキング不良？はい、それは効果があるようです。
何が起こっているのか説明していただけますか？グループステップがなぜ必要だったのか理解したいです。
Re: スタッキング不良？確かに、グループなしで分割すると、行ごとに文字通り分割され、アイテムにカテゴリの要素が欠けていることが認識されません。グループを使用すると、まずアイテム、次にカテゴリを確認することで、各カテゴリごとにレベルをアイテムごとに分割できます。
オンラインヘルプより ( https://www.jmp.com/support/help/en/18.2/?os=mac&source=application#page/jmp/split-columns-in-data-tables.shtml
グループ
選択した変数の各グループ内でデータを分割する場合は、グループ変数を指定します。各グループは出力テーブルに1行ずつ表示されます。また、必須変数、分割基準、および分割列も指定する必要があります。
注:グループ化する変数に不均等なグループが含まれている場合、または順序がランダムである場合は、それをグループ変数として指定すると、データが適切に再構成され、欠損値が適切な場所に割り当てられます。
それ以外の場合は、追加の行を入れてカテゴリとアイテムを定義し、その行のレベルを空白のままにしておく必要があります。
それが役に立つことを願います。
Re: スタッキング不良？考えれば考えるほど、意味がわからなくなってきました。split がどんな状況でもなぜそのような動作をするのか理解できません。まるで開発者がループをいくつかネストして、データが適切な場所に収まることを期待しているだけのように…。
私は、(a) 私がまだこの動作の根本的な原理を理解するにはあまりにも愚かなのか、(b) これは、入力が完全階乗であり、ユーザーがその仮定がなされていることを知っていることが期待される高パフォーマンス (大きなテーブルでの高速分割) を提供するためにこのように実装されたのか、(c) これは実際には提出/修正が必要な単なるバグなのか、という疑問が残ります。
（それが（a）であれば私は気分を害しません。;) ）
Re: スタッキング不良？あなたの考えを詳しく説明していただけますか？
私は反対の意見を主張します。
入力データが適切に構造化されている場合は、何も気にせずに Split できます。
入力データが適切に構造化されていないが、グループ化情報が追加されている場合は、このグループ化情報を使用して JMP に処理内容を指示できる可能性が常にあります。
機能しないもの:
ユーザーはグループ化情報（列がある）を知っていますが、JMP には伝えません（GUI 経由）。
そうすると、JMP がグループ化情報を使用しないのも不思議ではありません。
[JMP が推測や自動修正を適用し、ユーザーがその創造性に疑問を抱くケースもあります]。
Re: スタッキング不良？元の質問で提供されたデータセットについてどう思いますか？「適切に構造化されている」でしょうか？
また、テーブルを分割する際の JMP の現在の動作についてはどうお考えですか?
私の理解では、「分割基準」列とは、新しいテーブルの列ヘッダーに表示したい値を持つ列のことで、「分割列」とは、それらの新しい列のセルに表示したい値を持つ列のことです。この文脈における「グループ化」の意味がまだわかりません。
Re: スタッキング不良？初期データ テーブルは「適切に構造化」されています。
グループ化の概念は、入力データ テーブル内のどの行をグループ化して特定の出力行を定義するかという観点から考えることができます。
Re: スタッキング不良？別の言い方をすると:
「カテゴリ」と「レベル」の列（単体）は構造化されていません。次のような追加情報が必要です。
@Bハリスは次のように書きました:カテゴリー=B、アイテム=2 が欠落していることに注意してください。
他の人に事実を知らせるため: 行 #5 と行 #6 の間に何かが欠けています。
ケース1:
ユーザーはJMPに「アイテム」列の存在を伝えません（「アイテム」はGUIでは使用されません**）
そうすると、JMP にはその作業を適切に実行するのに十分な知識がありません。
ケース2:
3つ目のドロップゾーンがあります。ユーザーはこれを利用できます。
@Bハリスは次のように書きました:カテゴリー=B、アイテム=2 が欠落していることに注意してください。
グループ化列として構造化された方法で。
「グループ化」はあなたが望むことに非常によく適合します:
入力データのランク(行(), カテゴリ)ではなくグループ化列によって決定された特定の行にエントリを配置できるように、JMP に追加情報を提供します。
**） 編集：
「アイテム」はGUIで使用されます - 暗黙的に「すべて保持」を介して使用されます
しかし、これはあまりにも「受動的」です - 以下を参照してください。
Re: スタッキング不良？@hogi -- ここで、私がインターフェースのどこにもアイテム列を含めていなかったという考えが、誤解を招いています。そのため、おそらく Split アルゴリズムは実際にはその存在を認識していないのではないかという含意があります。
Split操作では*すべての*列が重要だと思い込んでいたようで、可能な限りすべての関係を維持しようとしていました。例えば、「lima」はアイテム「3」にのみ関連付けられていたのです。「すべて保持」を選択した場合、他のすべての列をグループ化列として扱うべきかどうか、今になって考え直しています…
いつかJMPマスターの地位を獲得し、完全に理解できればと思っています。そうすれば、JMPがグループロールで他のすべての「保持」列を暗黙的に使用しない理由が理解できるかもしれません。それまでは、JMPは私を不安にさせ続けるでしょう。なぜなら、これらの状況でのJMPの挙動は私にとって明確ではなく、特定が難しい状況下では誤った出力データが生成され、私が理解できるほど十分に文書化されていないからです。少なくとも、その不安感は、今後JMPを使用する際に、より注意深く行動することになるでしょう。
THX。
Re: スタッキング不良？すでに述べましたが、明示的に記述すると役立つかもしれません。
JMP は次のルールを適用します:
- グループ:グループ化して保存する
- 保持：保持する（〜落とさない）
@Bハリスは次のように書きました:
ここで、「すべて保持」を実行する場合、他のすべての列をグループ化列にする必要があるかどうかを調べています...
そうですね。
両方の方法を試して違いを確認してから決めることもできます。
グループはデータを「構造化」するのに役立ちます。データが既に構造化されている場合は問題ありませんが、構造化されていない場合は、意味のある出力が保証されます。
Keepを使うには、自分が何をしているのかを非常に正確に理解している必要があります。以下にいくつか例を挙げます。
コミュニティ内でのこうした小さな議論は、理解を深め、ユーザーの知識に挑戦し、磨くのに大いに役立ちます。
ユーザーコーチングセッションで出たJMP初心者の「面白い」質問を集めました。他のユーザーがJMPを理解するのに役立つようにまとめました。質問の多くは単なる修辞的なものですが、「JMPのスラング」がJMPのロジックの理解を難しくしている場合もあることを示しています。
@Bハリスはこう書きました:
それまでは、おそらく不安が残るでしょう。なぜなら、これらの状況での挙動が明確でなく、特定が難しい状況下では誤った出力データが生成され、私が理解できるほど十分なドキュメントも存在しないからです。少なくとも、この不安感は、今後このツールを使用する際に、より注意深く行動することになるでしょう。
同感です。「JMPが何をしているかを知る」ことは非常に重要です。しかも、ユーザーが適切な対応ができると感じられるレベルまで詳細に把握することが重要です。不安になったり、驚いたりする必要はないのです。予期せぬことが起こると、ユーザーは不安を感じ始めます。JMP が予期せぬことを行う他の箇所はどこにあるのでしょうか？！？！
JMP には素晴らしい機能があるかもしれませんが、少なくとも JMP の機能に期待していないユーザーにとっては、それが煩わしかったり、不安にさせたりするかもしれません...
こうした落とし穴のマップがあれば、ユーザーはそこから抜け出すのに役立ちます。JMPを安心して使用するために、すべてのJMPユーザーはこのようなマップを持つべきです。
詳細が適切に文書化されていても、JMP は非常に強力ですが、同時に、文書が少なすぎたり多すぎたりします。
そのため、適切な情報を見つけるのが難しくなります。LearnBot のおかげで、かなり簡単に見つけられるようになりましたが、それでもまだすべての詳細を把握しているわけではありません。
Re: スタッキング不良？グループ化せずに分割して保持する極端なケース
保つ: name (name is not used for grouping)
2 行が 1 行に結合されるため、多くの「名前」が失われます。
最初の*)項目が優先されるため、女性の名前から開始し、男性の名前はすべて削除されます。
全員男性の名前ですか？いいえ、最後には男性の学生が何人か残りました。
*) すべてのテーブル プラットフォームに共通する、どの値が保持され、どの値が失われるかという普遍的なルールはありません。
Join は最初の値も保持します (後続の値は考慮しません)。
更新はすべての値を保持しようとし、最後の値が「保持」されます。これが、Tables/Update が非常に遅い理由です (コマンドの実行に数時間かかる場合があります)。Tables /Update を高速化します。
Re: スタッキング不良？
@hogi さんは書きました:
最初の*)アイテムが勝ちます
おっと…これは、 保つ経由で追加された列にのみ当てはまります。
列を分割するの場合、Split は Update のように動作し、最後の列が「固定」されます。
最終的なデータセットに含まれる「名前」エントリとM/F分割エントリをマークしたこの例で説明してみました。次のようになります。
-保つ(名前など)で追加された列:ランク=1 (最初の列を取得し、後続の列をスキップ)
- 列の分割(高さ --> M/F) で追加された行: RankReverse=1 (最後の 1 つが「固定」されます)
Re: スタッキング不良？この動作はロジックに従いますが、そのロジックがわかりやすいか、すべてのユーザーが期待するものかどうかについては議論の余地があります:)
すべて保持がデフォルトとして正しい選択なのだろうか？JMPが
... 「すべて保持」オプションを有効にしたユーザーは、ドキュメントを参照して、それが希望どおりに機能するかどうかを確認できます。
JMP は、「Keep を使用しますか? グループを使用する方がよいでしょうか?」という警告を表示することもあります。
下線部: オプションを使用しないユーザーにとって、驚きはありません | 不安はありません。
Splitよりも危険: テーブル / 更新
デフォルトのインターフェースも「すべて」で始まります
a) 列の追加
b) 列の置換 (!)
数年前、私は、デフォルト設定を次のように置き換えるアドインを作成することは危険だと考えました。
追加の利点: この変更により、プラットフォームは数千の列を更新しようとする設定で起動しなくなります。
これにより、元のものよりも桁違いに高速になります 
https://community.jmp.com/t5/JMP-Wish-List/Speed-up-Tables-Update/idc-p/653334/highlight/true#M4531
Re: スタッキング不良？注意: Jmpが予期しない動作をする箇所にトピックを追加しました
Re: スタッキング不良？いつか、split（とstack）が何をしているのかを示すアニメーションを見てみたいと思っています。split-by列の値が列ヘッダーにプッシュされ、split-by列がそれらの新しい列のセルにプッシュされる様子を想像しています。（split-by列に複数のsplit-by列がある場合、番号付きの新しい列が作成されることを知って、今驚きました。）
しかし、本当に興味深いのは、複数の値が同じセルに収まろうとするなど、競合が発生した時です。JMPはこのような状況が発生すると警告を発します（これは素晴らしいことです！）。しかし、この記事は、正しく分割されているように見えたデータセットから生まれたものです。しかし、詳しく調べてみると、正しく分割されていないことが分かりました。私は警告の意味を理解していなかったため、無視していました。
私としては、警告を次のように変更する必要があります: 「保持する列の複数の行 (異なる値を持つ可能性があります) が、分割テーブル内の同じ行にマップされています。各列の 1 つの値のみが保持されます。」 ---> 「複数の値が同じセルにマップされており、1 つだけが保持されます。」
Re: スタッキング不良？
@Bハリスは次のように書きました:
特定の分割列に複数の分割列がある場合、新しい番号付き列が作成されることを知って驚きました。
複数の分割列が使用されている場合、JMP は分割列の名前と分割列のエントリの組み合わせとして列名を作成します。
分割列として 1 つの列のみを選択した場合、分割列の名前は列名に含まれません。
私が Big Class を使用して JMP の機能を説明し始めると、同僚はあきれ返ります。
しかし、代替データ セットを使用して設定を変更するのは素晴らしいトリックです。
「M」と「F」があれば、JMP が何を実行しているかは明らかであり、元のデータ セットに表示された「数字」について疑問に思う必要はありません。
Big Class は非常にシンプルに見えますが、多くの詳細を説明するには複雑です。
共線性が欠けているだけです...
