BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
Zatere
Quartz | Level 8

Hi there,

 

I would have a general question.

 

I have done some changes in the way a program generates results, such as averages, mean etc. For example, I have reduced the number of data steps by combining those many steps in one bigger query.

 

At the end of the process I export the data sets as excel files.

 

When I compare the results of the amended code with the original code in excel, I don’t get any discrepancies.

 

However, when I compare those in SAS using PROC COMPARE for some of the variables in those data sets I get really small discrepancies like 4.589E-13. The difference is very small, in this example it is only 0.0000000000004589.

 

Is there any explanation why that is happening? Is it the way that SAS make the calculations or the results are wrong?

 

Thanks!

1 ACCEPTED SOLUTION

Accepted Solutions
FreelanceReinh
Jade | Level 19

Hi @Zatere,

 

These are typical rounding errors due to finite-precision arithmetic.

 

Simple example: Mathematically, 2/3 + 2/3 = 4/3. But if the operands are stored only with a finite number of decimals, the left-hand side is something like 0.6666...6670.6666...667 = 1.3333...334, whereas the right-hand side is correctly rounded off to 1.3333...333, so the results will differ regardless if the finite precision is 12, 25 or even 1000 digits.

 

In the case of machine arithmetic we're talking about binary digits rather than decimal digits, which makes things even worse, as shown by the example below:

data _null_;
a=0.1+0.3+0.7;
b=0.1+0.7+0.3;
c=1.1;
if a=b then put 'equal';
else put 'unequal';
put (a b c) (/ =hex16.);
run;

With SAS 9.4 under Windows the result in the log is most likely:

unequal

a=3FF199999999999A
b=3FF1999999999999
c=3FF199999999999A

That is, just because of a different order of summands, the result in b is affected by rounding error and thus differs from a and c.

 

In PROC COMPARE you can use the CRITERION= and METHOD= options to simplify the result in the presence of such irrelevant small differences.

View solution in original post

2 REPLIES 2
FreelanceReinh
Jade | Level 19

Hi @Zatere,

 

These are typical rounding errors due to finite-precision arithmetic.

 

Simple example: Mathematically, 2/3 + 2/3 = 4/3. But if the operands are stored only with a finite number of decimals, the left-hand side is something like 0.6666...6670.6666...667 = 1.3333...334, whereas the right-hand side is correctly rounded off to 1.3333...333, so the results will differ regardless if the finite precision is 12, 25 or even 1000 digits.

 

In the case of machine arithmetic we're talking about binary digits rather than decimal digits, which makes things even worse, as shown by the example below:

data _null_;
a=0.1+0.3+0.7;
b=0.1+0.7+0.3;
c=1.1;
if a=b then put 'equal';
else put 'unequal';
put (a b c) (/ =hex16.);
run;

With SAS 9.4 under Windows the result in the log is most likely:

unequal

a=3FF199999999999A
b=3FF1999999999999
c=3FF199999999999A

That is, just because of a different order of summands, the result in b is affected by rounding error and thus differs from a and c.

 

In PROC COMPARE you can use the CRITERION= and METHOD= options to simplify the result in the presence of such irrelevant small differences.

hackathon24-white-horiz.png

2025 SAS Hackathon: There is still time!

Good news: We've extended SAS Hackathon registration until Sept. 12, so you still have time to be part of our biggest event yet – our five-year anniversary!

Register Now

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

SAS Training: Just a Click Away

 Ready to level-up your skills? Choose your own adventure.

Browse our catalog!

Discussion stats
  • 2 replies
  • 1077 views
  • 0 likes
  • 2 in conversation