やあ、
JMP で説明できない奇妙な問題が発生しています。 私のテーブルでは、2 つの列の値を比較しています。 列「A」は、0 ～ 100 の範囲の整数値を含む単純な連続数値列です。 列 "B" は、0 ～ 1 の範囲の数値を含む別の単純な連続数値列で、すべて小数点以下 2 桁までの精度があります。 次に、列「C」を作成し、「C」に数式 B*100 を設定して、「A」と「B」を直接比較します。 ただし、列「A」と「C」を比較すると、場合によっては、A と C は実際には等しいのに、JMP では等しくないと言われます。 これは単純な比較であるはずですが、何らかの理由で特定の数値は比較できません。 列「C」を文字に変更してから数値に戻すと、この問題は解決しますが、実際にはこれを行う必要はないような気がします...根本的な問題を説明していただけますか?
考えられるすべての数値をリストしたサンプル データセットを添付しました。 行 7、14、28、29、55、56、57、および 58 で問題が発生していることがわかります。
ここで何か洞察があれば幸いです。
ありがとう、
メリッサ
ああ、そうです、その通りです。 本当にありがとう！
問題は浮動小数点/2 進数にあります。すべての数値を入力どおりに正確に保存できるわけではありません。これはコンピュータに関する長期的な事実の 1 つです。そして、JMP はその数値データをこの式に保存し、表示時に修正値に戻します。これは、数値解析を実行するほぼすべてのシステムの問題です。
昔のことを思い出せば、数字の 3 は保存できないと思います。実際には 2.9999999999998 のような値として保存されます。3 については間違っているかもしれませんが、理解していただければ幸いです。
@melissacch 、
データをコピーしたり手動で入力したりする代わりに、テーブルのスクリプトを作成してみてはいかがでしょうか?
ここに一例を示します。 一連の小数を生成する簡単な方法がわかりません。 しかし、このようなことをすれば、丸めの問題を回避できると思います。
dt = New Table();
Set1 = Index(1,100);
Set2 = Index(0.01,1); // This doesn't work
dt << New Column("A",Format("Fixed Decimal",10,2),Numeric,Continuous,<< Set Values(Set1))
<< New Column("B",Format("Fixed Decimal",10,2),Numeric,Continuous,<< Set Values(Set2))// Will Fail
<< New Column("B*100",Format("Fixed Decimal",10,2),Numeric,Continuous,Formula(:B*100))
<< New Column("Check1",Format("Fixed Decimal",10,2),Numeric,Continuous,Formula(:A == :Name("B*100")));やあ@uday_guntupalli
ご返信ありがとうございます。 違いを見て、それが丸めの問題であることがわかるはずでした。 しかし、なぜ JMP がこのようなわずかな違いを生み出しているのか、考えはありますか? これらの数値は手動で入力しているため、これ以上の小数点以下の精度はありません。
@melissacch 、
丸め誤差の問題です。 添付したデータ テーブルを見ると、両方の列の差が計算される新しい列が追加されています。 微小な値があるため、JMP は等しくない値を返します。
お役に立てれば
