为什么根据proc比较在proc中找到平均值和proc sql步骤会产生不同的结果？答案

【问题标题】：Why does finding the average in a proc means and a proc sql step yield different results according to a proc compare?为什么根据proc比较在proc中找到平均值和proc sql步骤会产生不同的结果？
【发布时间】：2017-12-13 15:06:33
【问题描述】：

我有以下代码。创建的数据集是test_means 和test_sql。两者都取您选择的变量的简单平均值。

两者都通过eye创建完全相同的数字。

为什么proc compare 说这些值不等于一个愚蠢的小值，比如 0E-14？这与两个过程中数字的存储方式有关吗？

%let var=; *Insert numeric variable to check;
%let dsn=; *Insert dataset name;

proc means noprint mean data=&dsn.;
    var &var.;
    output out=test_means (keep=_STAT_ &var. where=(_STAT_="MEAN"));
run;

proc sql;
    create table test_sql as select
        "MEAN" as _STAT_ length=8,
        mean(&var.) as &var.
    from &dsn.
    ;
quit;

proc compare data=test_means compare=test_sql;
run;

【问题讨论】：

查看 PROC COMPARE 的文档。特别是 METHOD= 选项。
我认为这只是使用浮点数引起的舍入误差。最近不是有一篇帖子有人展示了数据处理顺序影响操作结果的示例吗？
这些不是显着差异。查看 PROC COMPARE 中的 FUZZ 选项或软件中的数值精度。
我完全理解它们不是显着差异，但它们仍然是差异，我可能会被要求解释它们。操作顺序听起来不错，我会阅读的。
E-14 级别的差异不是任何有意义的差异——不仅不是显着，而且它们不是实际差异。低于E-12 的任何内容都应该被视为计算机存储事物的人工制品，除非您专门从事的工作预计会有如此大的差异。

标签： sql sas compare mean sas-macro

【解决方案1】：

对浮点值（如 SAS 数字）进行的计算预计会出现 E-14 顺序的差异。这与不同的 PROC 没有特别的关系；所要做的就是以不同的顺序对值求和，以产生沿着这些线的错误。即使在 PROC SQL 中的两次不同运行也可能产生如此大的差异，如果行最终处理方式不同（例如，由于多线程）。

PROC COMPARE 运行通常应使用FUZZ 选项来完成，除非您要比较的数字非常小。这通常应该是标准实践的一部分，除非您特别想看到这种差异（意思是，除非您想验证两个文件是同一个文件，而不仅仅是相同的值）。

【讨论】：