Not getting expected results from FLOOR function on a whole number

[LRogers]

Hello!

I have numeric values within my data where I simply would like to just drop the digits after the decimal point so I have a whole number.

Example:

Have 460.2866667

Want 460

Have 318.9816667

Want 318

So I am using the FLOOR function which is returning the correct results.

The problem i'm running into though is when I have a whole number....this is what is happening with the FLOOR function:

Have 824

Getting 823

Technically since the number is 824.00000000 and I want to just drop the numbers after the decimal point, I would hope to get a value of 824.  

I tried FLOORZ and INT but it still gives me the 823 result.

Anyone have any ideas how to solve this?

Thank you!

[PaigeMiller]

Almost definitely, your 824 is not an integer but actually 823.999999...

So floor is giving the correct answer. If you change the format of your variable to something like BEST32.16, do you see 824 or do you see 823.9999999...

[LRogers]

yes, when I do change to that format I see 823.99999999999

[FreelanceReinh]

---

@LRogers wrote:

yes, when I do change to that format I see 823.99999999999

---

Hi @LRogers, 

Please note that you were just lucky that one of the common numeric formats (such as w.d, BESTw. or Ew.) revealed the small difference (most likely a rounding error) between the stored number and 824 directly. There are several different numbers which these formats would display as if they were exactly 824, because these formats do some rounding. (Needless to say, this is no special feature of the number 824.)

Here are examples (assuming Windows or Unix operating systems):

data test;
input x hex16.;
cards;
4089BFFFFFFFFFFE
4089BFFFFFFFFFFF
4089C00000000000
4089C00000000001
4089C00000000002
;

Among the above five numbers (entered as their internal hexadecimal representations) only the third is equal to 824, but you would need either

• a special format, ideally one that shows the internal representation (such as BINARY64. or HEX16.)
• or the (non-default) system option setting DECIMALCONV=STDIEEE (in conjunction with a sufficient w.d format, e.g. 17.13)

in order to distinguish it from the other four values by just looking at a formatted value.

data _null_;
set test;
put x best32. +1 x 32.28 +1 x hex16.;
run;

Result (under Windows SAS 9.4 using the default DECIMALCONV=COMPATIBLE):

                             824 824.0000000000000000000000000000 4089BFFFFFFFFFFE
                             824 824.0000000000000000000000000000 4089BFFFFFFFFFFF
                             824 824.0000000000000000000000000000 4089C00000000000
                             824 824.0000000000000000000000000000 4089C00000000001
                             824 824.0000000000000000000000000000 4089C00000000002

Numbers like the four "deviating" cases above can easily result from calculations (as a consequence of rounding errors in floating-point arithmetic and numeric representation error):

data have;
x1=906.4/1.1;
x2=0.00824*100000;
run; /* Mathematically, both calculations result in 824, but ... */

proc print data=have noobs;
format x: hex16.;
run; /* ... not using the computer's floating-point arithmetic. */

Result (Windows SAS 9.4):

              x1                  x2

4089BFFFFFFFFFFF    4089C00000000001

So, it's always good to have the ROUND function at hand.

[Tom · Accepted solution]

ROUND() the number first.

 2  data x;
 3    a=824;
 4    b=824 - 1E-10 ;
 5    floora=floor(a);
 6    floorb=floor(b);
 7    floorb2=floor(round(b,1E-5));
 8    put (_all_) (=/) ;
 9  run;


a=824
b=824
floora=824
floorb=823
floorb2=824

[LRogers]

This is great!  The floor(round...)) worked perfectly!  Thank you!