caluculed in sas proc

[FreelanceReinh]

The documentation of the ORDER BY clause, for example, says: "Without an ORDER BY clause, the order of the output rows is determined by the internal processing of PROC SQL, the default collating sequence of SAS, and your operating environment." That order does matter for certain calculations, has been demonstrated by PG's example.

I don't know whether it is the platform ("operating environment") in your specific case. You haven't told us so far, how you obtained your results and whether different platforms were involved at all.

You will hardly be able to identify the problem in the SAS log, because from SAS's perspective everything was done correctly and as usual. It won't reveal any details about the "internal processing of PROC SQL" mentioned above.

When you're asking about the "best result", are you really concerned about those tiny differences like the 3E-20 in PG's example?

[LineMoon]

My OS is unix , AIX 6.1

[PGStats]

The precision of numerical methods is a huge topic in itself that is covered in any introductory numerical analysis course.

Try Googling rounding error numerical analysis.

[ballardw]

---

@PGStats wrote:

The precision of numerical methods is a huge topic in itself that is covered in any introductory numerical analysis course.

Try Googling rounding error numerical analysis.

---

And should also be covered in any serious programming course.

In a significant number of general programming languages you specifically the precision of storage when declaring variables and incautious assignments can lead to, let us say, interesting results.

If I remember correctly IBM370 assembler language had something like 16 ways to add numbers. Depending on the specific add and the types of variables you could very easily have a+b not equal to b+a .

[LineMoon]

Thank you

Please, can I have an exemple for a+b is not equal to b+a ?

[LineMoon]

I use sas 9.2 under unix : AIX 6.1

[Reeza]

Any number that can't be represented exactly in binary can be different.

[LineMoon]

Please, can I have an exemple in sas.

When I do like this, I get a_b=b_a and I want to get an exemple with a+b is différent from b+a.

data test;

a=1/3;

b=2/3;

 a_b=a+b;

b_a=b+a;

run;

There is no difference beteween a_b and b_a ?

Thank you.

[FreelanceReinh]

Hello @LineMoon,

Please see my reply in the separate thread where you posted this question.

As you saw from one of PG's posts in this thread, there are such examples with three summands. This has to do with the fact that the associative law of addition, (a+b)+c=a+(b+c), breaks down indeed when numeric representation issues come into play. This is explained in one of the standard references on the subject, SAS Technical support document TS-230 "Dealing with Numeric Representation Error in SAS Applications...

I believe, the examples of a+b not equal to b+a which @ballardw remembered, were specific to the IBM mainframe environment he worked in.

If you're interested in further "surprising" results which other programmers came across recently, here are three discussions from last month where I contributed detailed answers, including references and general information:

• https://communities.sas.com/t5/Base-SAS-Programming/decimal-places-Calculaitons/m-p/237767
• https://communities.sas.com/t5/Base-SAS-Programming/ceil-function-bug/m-p/239275
• https://communities.sas.com/t5/General-SAS-Programming/Multiplication-Error-After-some-Digit/m-p/239...

"Classical" results include elementary calculations such as:

data _null_;
if 0.1+0.7~=0.8 then put 'This';
if 3*0.3<0.9    then put 'cannot';
if 9.9/3>3.3    then put 'be true!';
run;

In 2012 I observed a case where two identically defined variables in the same data step contained different values (see the other thread).

More recently (2015, with SAS 9.4 on Windows 7) I encountered examples where the internal value of a decimal fraction changed when adding trailing zeros or writing it in exponential notation:

data _null_;
if 0.00001 ne 1.0E-5   then put 'surprise 1';
if 0.00001 =  1E-5     then put 'OK 1';
if 1E-5 ne 1.0E-5      then put 'surprise 2';
if 1.0E-5 = 1.00E-5    then put 'OK 2';
if 1.00E-5 ne 1.000E-5 then put 'surprise 3';
if 1E-5 = 1.000E-5     then put 'OK 3';
if 0.00001 ne 0.0000100000000000000000000 then put 'surprise 4';
run; /* All IF conditions, including the surprising ones, evaluate to true. */

As it turned out, you can write the numeric literals 1.0E-5, 1.00E-5, 1.000E-5, ... with up to 308 zeros (cf. CONSTANT('SMALL')=2.2250738585072E-308). In this sequence, the internal value stored by SAS changes 96 (!) times in a strange pattern between four different binary floating-point representations. In numeric literals without exponential notation it seems that these effects start only when "too many" decimals are involved: e.g. 0.788999999999999757 ne 0.7889999999999997570.

@All: If you encounter a new class of unexpected results in the context of numeric representation in SAS, please let me know.