行を選択/選択解除すると列の式が再評価されるのはなぜですか?約 100,000 行と 2,000 列からなるデータテーブルがあります。これらの列の数十には数式が含まれています。どこかに変更を加えると、ステータス バーに「##column_xyz を評価中」と表示され、データ テーブル内のすべての式の評価が続行されます。これはかなり大きなテーブルであり、多くの式があるため、すべての式を評価するには最大 60 秒かかります。そのため、数式の評価をトリガーするアクションの実行には非常に敏感です。ユーザー インターフェイスは終了するまで応答しなくなり、予期せぬ事態が発生すると非常に迷惑になるためです。一方で、常に「式の評価を抑制」することは望ましくありません。時々、それを忘れてしまい、データが更新されるべきときにデータが更新されないことがあるためです。
したがって、この大きなデータ テーブルには、グラフ ビルダー プラットフォームを使用して一連のチャートを生成し、いくつかのローカル データ フィルターを適用し、データの選択的な強調表示を実行する JSL スクリプトがあります。基本的に、スクリプトの目的は、グラフを動的に生成し、電子メールやレポートにカット アンド ペーストできるように準備することです。
このスクリプトの実行には時間がかかるようです。必要以上に長いです。UI は、最終的にグラフが表示されるまで、約 60 秒間応答しなくなりました。私はその 60 秒間に何が起こっているのかを理解するために時間を費やしました。その後、どういうわけか数式の評価がこのスクリプトによってトリガーされていることに気づきました。データ テーブルのステータス バーには通常の「評価中...」メッセージが表示されないため、これはすぐには分かりませんでした。おそらく評価がユーザーアクションではなくスクリプトによってトリガーされているため、空白のままになります。[スクリプト ログ] ウィンドウが開いているときにスクリプトを実行すると、ログ ステータス バーに「##column_with_formula を評価中」と表示されました。遅延の長さから、実際にはテーブル内のすべての数式列が評価されていたと思われますが、ログ ステータス バーはそのメッセージでフリーズしました。そして、テーブル全体に対して「式の評価を抑制」を有効にし、スクリプトを再度実行することで、式の評価が原因であることを確認しました。グラフはほぼ即座に表示されました。
試行錯誤を経て、スクリプト内の 1 行に絞り込みました。「Select Where」は、生成されたグラフ上のデータの一部を強調表示するために使用されます。次のようになります。
myDT << Select Where( :Name("##column_with_formula") == "value" );私はこれは奇妙だと思いました。おそらくそれは「場所」の部分に関係があるかもしれません。そこで、この行をもっと単純なものに置き換えました。
myDT << Select Rows( {1,3,5,7} );この行でも、依然として舞台裏で式の評価がトリガーされているようです。次に、さらにいくつかの実験を行いました。
- タスク マネージャーを開いた状態で、通常の方法 (列の値を変更) で数式評価をトリガーしました。ステータス バーには評価中の数式が表示され、即座に CPU 使用率が 30% まで上昇しました (1 つの CPU コアが最大化)。
- アクティビティが停止するのを待って、UI を使用してデータ テーブルの行を選択してみました。ステータスバーは変化しませんでした。まだ「評価完了」と表示されていました。しかし、タスク マネージャーは、数式の評価が行われているかのように、まったく同じ CPU アクティビティを示しました。
- データテーブルの「式の評価を抑制」を有効にし、データテーブルの別の行を選択しました。CPU 使用率は急増しませんでした。
要約すると、実験を通じて次のことを実証しました。
- JMP は列式の評価を不必要に実行します。ユーザー インターフェイスとの基本的な対話により、実際には入力データがまったく変更されていない場合でも、バックグラウンドで計算が行われます。
- JMP は、これらの数式評価をいつ実行するかについては透明ではありません。ステータス バーにメッセージが表示されることもありますが、ほとんどの場合、これが発生していることを示すものはありません。これは多くの場合、明確な理由もなく、ユーザー インターフェイスの遅延、途切れ、無応答として現れます。
- 1 つの列の評価がトリガーされると、必要かどうかに関係なく、すべての列が評価されるようです。
データセットが小さく、数式が少なく、複雑性も低いため、過剰な数式評価は問題にならないようです。しかし、十分に複雑な数式と大規模なデータセットがある場合、これは実際の障害になります。私の場合は、式 eval を常に抑制したままにし、手動でのみ式を評価することに適応する必要があると思います。ただし、ワークブックの再計算が手動に設定されている Excel と同様に、これは間違いが発生しやすくなります。少なくとも Excel には、変更されたデータに対して必要な数式のみを評価できる依存関係ツリーがあり、ユーザーが数式を適切に設計すれば、最小限のオーバーヘッドで計算を常に自動のままにすることができます。確かに、私は Excel ほど JMP に詳しくないので、JMP でこれに対処する方法がまだ学んでいない可能性があります。
eval を常に抑制せずに、大量の複雑な数式を管理する方法について何か提案がある人はいますか?
また、投稿のタイトルにあるように、行選択の変更が式の評価をトリガーする理由を知りたいと思っています。また、なぜ JMP は式を評価していることを伝えたり、隠したりするのですか?
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?@Chris_Rodrigues書きました：
また、私にとって最も驚いたのは、選択行の完全な再評価がトリガーされました (CPU 使用率と UI の応答性から明らかです)。行を除外することによって数式が影響を受ける可能性がある場合、ユーザーが実際に操作を行ったときに評価をトリガーしないのはなぜでしょうか。行を除外します?理論的には、ユーザーが現在の行選択状態に応じて列の数式を作成できる可能性があると思いますが、それはまれなエッジケースのように思えます。
これも私を混乱させます。 Jmp が行の状態を区別しないのはなぜですか:除外されるそして選択された?
たとえ行状態変更されました - 後続のチェックが行われる可能性があります。除外()状態が変わりました。
同意する@Chris_Rodrigues - ほとんどの列の数式では、除外()そしてそうではありません選択済み() 。
【ただし、選択済み()最高にクールです:)]
ニッチな問題とは思えません。 データ行が 5 ～ 1000 行のサンプル データの場合、これは大きな問題ではありません。
しかし、より大きなデータセットの場合、除外()列の数式は多大なペナルティを支払わなければなりません。
Names Default to Here(1);
dt = new table("test", add rows(5),
New Column( "again"),
New Column( "excluded",
Formula(
:again[1] = 1;
Excluded();
),
));
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?まあ、これに苦しんでいたのは私だけではなかったとようやく聞けてうれしいです。ほぼ4年経った今でも、この状況は改善されていません。式の評価がテーブル全体で抑制されているはずの場合でも、データ テーブル全体で式の評価をトリガーするあらゆる種類の奇妙な状況が存在します。依存関係を処理する方法がないため、個々の列で式の評価を抑制することはできません。JMP が正しい順序で評価するには、すべての列の抑制を解除する必要があります。また、JMP16 では、式評価エンジンがさらに遅くなったように見えます。現在、完全なテーブルを評価するのに異常な時間がかかります。
このことと、すべての式を削除して固定値のみを保存するというフォーラムでの絶え間ない提案の間で、私は、JMP は動的な式を扱うことを意図したものではなく、静的なデータのみを扱うことを意図しているという結論に達しました。テーブルが小さく、まだ適切に機能する場合、最初は数式は便利ですが、数式の数、数式の複雑さ、または行数が特定の制限を超えると、レンガの壁にぶつかります。他のツールを使用してこのプロジェクトを完全に作り直し、グラフ作成/プレゼンテーション/統計のみに JMP を使用する必要があります。
これを解決済みとしてマークします。解決策はないということです。この問題が発生している場合、JMP はその作業に適したツールではありません。動的数式を削除し、静的データのみを保存します。
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?大規模なデータテーブルでも同様の問題が発生しました。
式の評価が何度もトリガーされました。
テーブルを保存して再度開くと、すべて問題ありませんでした。
したがって、おそらく再評価は変数名の競合によって引き起こされたのでしょう。 そして変数名をリセットすると問題は解消されました。
他のユーザーも同様の問題を抱えている場合は、個々の数式をすぐに有効または無効にしたいと考えています。
数式の計算を有効/無効にする簡単な方法
もう 1 つのアイデア: デフォルトで式の評価を無効にし、そのような偽の式の再評価を行わずにスムーズな Jmp を実現します。
データ テーブルにデータを追加する場合は、1 回限りの数式評価をトリガーするだけです。 願い事はこうです。
特定の式に対して 1 回限りの式評価をトリガーする迅速な方法
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?このテーブルは古いバージョンの JMP で作成されたものではありません。おそらく1年前のものなので、JMP 13または14のいずれかでした。
赤い三角ボタンのメニューを使用して、テーブルの評価を抑制するボックスをチェックし、それを保存して閉じました。テーブルを再度開くと、評価抑制ボックスがチェックされなくなるため、テーブルを保存してもテーブル全体の設定が保持されなかったようです。テーブルが開くと、ステータス バーにすぐに「xyz を評価中...」と表示されます。何がこれを引き起こしているのかわかりません。
一部のデータ検索関数で使用されるいくつかの連想配列にデータを設定するために使用されていた OnOpen スクリプトがありました。OnOpen の名前を別の名前に変更して無効にし、テーブルを開いたときに起動しないようにしましたが、評価は引き続き行われます。
テーブルの保存時にこのオプションが保持されることがわかっているため、ほとんどの数式列の列プロパティに移動し、そこで eval を抑制する JSL スクリプトを作成しました。 そのため、テーブル全体の評価にそれほど時間がかかりません。今後はこのように対処することになると思います。個々の列の eval を抑制し、数式の実行が必要な新しいデータをインポートするときは、スクリプトを使用して一時的に抑制を解除します。
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?開いたときに評価する数式を含むテーブルを作成できませんでした。@chungwei
この設定は、JMP 5 程度で作成された JMP テーブルに影響を与える可能性があります。現時点では何も行われていないように見えます。
データ テーブルの赤い三角形のオプションを使用して、数式の評価を抑制し、その状態 (部分的に評価された列を含む) でテーブルを保存することができます。 同じ赤い三角形から rerunFormulas を使用して (または JSL から) 更新を強制できます。 (これがあなたが求めているものかもしれません。)
知事が言う理由推奨されませんテーブルに抑制ビットが設定されると非常に混乱するのでしょうか...あるいは、一度はそうなりました。
テクニカルサポートに問い合わせると、欠陥を入力して追跡します（または、その設定が存在する理由と、それが古い形式のテーブルで何をしたか、または何をしたかを解明します）。
デバッグ/ロギング フレームワークはありません。
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?クレイジ、それは、数式が評価されているときにログに書き込むことをお勧めします。この手法を使用して、数式の評価に関連するプロジェクトの UI の遅れと遅延をさらにトラブルシューティングします。私の方法はそれほど正確ではありませんでした。しかし、質問があります。JMP にオンにできる「デバッグ」モードまたは「詳細ログ」機能はありますか?特定の瞬間に JMP が何を行っているかを把握するためだけにコードにそれほど多くの Write ステートメントを組み込む必要がなければ、素晴らしいと思います。
ただし、今のところ、現在の作業ではこのプロジェクトをそのまま使用する必要があります。式の評価を完全に抑制し、必要に応じて式を手動で再実行したいだけです。環境設定メニューで「開くときに評価を抑制」を有効にしても、JMP はテーブルを開いたときにすぐに数式を評価します。このテーブルのすべての自動式評価を完全に防ぐ方法はありますか?この設定でこれが行われることになっているのに機能しない場合、バグレポートを送信する方法はありますか?
参考までに、私は Windows 10 x64 で JMP PRO 14.1 を使用しています。
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?実行している JMP のバージョンは何ですか?
私の知る限り、14 は期待どおりの動作をしています。これが私のテストJSLです
New Table( "Untitled", add rows(3),
// EVERYTHINGCOL depends on everything. it evaluates last.
New Column( "EVERYTHINGCOL", Formula( Write( "\!nEVERYTHINGCOL,row" || Char( Row() ) ); :ROWSTATECOL + :INDEPCOL + :DEPONINDEP; ) ),
// DEPONINDEP depends on INDEPCOL, but not ROWSTATECOL.
New Column( "DEPONINDEP", Formula( Write( "\!nDEPONINDEP,row" || Char( Row() ) ); :INDEPCOL + 1; ) ),
// INDEPCOL is independent. It evaluates early, maybe first.
New Column( "INDEPCOL", Formula( Write( "\!nINDEPCOL,row" || Char( Row() ) ); 17; ) ),
// ROWSTATECOL is directly dependent on row state information. It evaluates early, maybe first.
New Column( "ROWSTATECOL", Formula( Write( "\!nROWSTATECOL,row" || Char( Row() ) ); Selected( Row State() ); ) ),
)
ログを見てください。列は評価どおりにレポートします。 行を選択すると、列のうち 2 つが評価されますが、他の 2 つは評価されません。
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?[テーブル] の下の [設定] メニューには、[開くときに式の評価を抑制する (推奨されません)] というオプションがあります。このオプションをオンにしましたが、機能しないようです。データテーブルを開くと、式 eval が抑制されていない状態から始まりますが、それでも手動で抑制する必要があります。このオプションは壊れているのでしょうか、それとも私がこのオプションの意図を誤解しているのでしょうか?
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?クレイジ、私が言いたいのは、すべての数式が再計算されるということです行の状態に依存するかどうか。数式の大部分は行の状態とは何の関係もありませんが、行の状態が変化すると再計算が必要になります。おそらく、存在する可能性のあるあらゆる種類の式に影響を与える可能性のある何かが起こった場合、JMP は常にすべてを計算していると思います。私の考えでは、それは不必要で非効率的です。メスで十分なときに戦斧を使うようなものです。確かにそのようにプログラムをコーディングする方が簡単です。これは単純なアプローチのように思えますが、これが JMP が式の評価をどのように処理するかを知ったときは驚きました。
数式の計算方法がよく理解できたので、数式の eval を抑制し、 dt << runFormulas; を挿入することで、この問題を確実に回避できます。および待機(0);私のスクリプト全体にわたるステートメント。きれいではありませんが、うまくいくと思います。
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?はい、式が行状態情報に依存している場合、行の選択を変更すると、その列とそれに依存する列が再評価されます。
行の状態を変更した後に dt<Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?
ジム、返信ありがとう。このテーブルには時系列データが含まれており、最新のデータを定期的にインポートしています。新しいデータがテーブルに追加された後にそのデータに基づいて計算されるように、数式を保存したいと考えています。
これらの式の大部分では、値は同じ行内の他のデータにのみ依存します。テーブルの前の方のデータを除外しても、以下の値には影響しないため、列全体の再計算は不要ですが、とにかく再計算が行われます。これが、数式に Col Maximum() や Lag() などの関数が含まれている場合にのみ発生し、数式が他の行の値の影響を受けるようになれば便利です。
また、私にとって最も驚いたのは、選択行の完全な再評価がトリガーされました (CPU 使用率と UI の応答性から明らかです)。行を除外することによって数式が影響を受ける可能性がある場合、ユーザーが実際に操作を行ったときに評価をトリガーしないのはなぜでしょうか。行を除外します?理論的には、ユーザーが現在の行選択状態に応じて列の数式を作成できる可能性があると思いますが、それはまれなエッジケースのように思えます。
Re: 行を選択/選択解除すると、列の式が再評価されるのはなぜですか?特定の列のセルの選択/除外の変更によって数式が影響を受ける可能性があるため、再計算が行われます。データ テーブルのサイズを考慮すると、数式の値が変更されない列を変更することを検討し、その後、[数式] プロパティを削除して、それらを一般的な数値列に変えます。
