Rounded Values

This is an issue that is related to computer storage and memory designs. Different systems may hold and display numerical values at different levels of precision, but this rarely matters in practice. Still, there is always some type of rounding being displayed in large sets of computer-generated numbers and this is an example.

For example, you may be looking at 2.700000048 as a 'cell' value using data imported into EXCEL, but see that EXCEL prints out such a cell as 2.7. Or you may see 2.70 on Yahoo Finance or a Bloomberg terminal screen, but since this a 'rounded-to-the-second-decimal-place' value, you cannot be sure that the actual stored value is not 2.700000048. In fact, it is likely that the stored value is 2.700000048, simply because 2.70 cannot be exactly represented in a computer's set of binary (0/1) memory registers.

Here is what text output through WRDS shows

PERMNO DATE TICKER PRC

88337 20010601 ECMN 2.55000
88337 20010604 ECMN 2.55000
88337 20010605 ECMN 2.55000
88337 20010606 ECMN -2.56500
88337 20010607 ECMN 2.63000
88337 20010608 ECMN 2.55000
88337 20010611 ECMN 2.70000
88337 20010612 ECMN 2.50000
88337 20010613 ECMN 2.50000
88337 20010614 ECMN 2.47000
88337 20010615 ECMN 2.47000
88337 20010618 ECMN 2.35000
88337 20010619 ECMN 2.35000
88337 20010620 ECMN 2.37000
88337 20010621 ECMN 2.37000
88337 20010622 ECMN 2.26000
88337 20010625 ECMN 2.25000
88337 20010626 ECMN -2.36000
88337 20010627 ECMN 2.25000
88337 20010628 ECMN -2.25500
88337 20010629 ECMN 2.25000

and here is the comma delimitted output

PERMNO,DATE,TICKER,PRC
88337,20010601,ECMN,2.549999952
88337,20010604,ECMN,2.549999952
88337,20010605,ECMN,2.549999952
88337,20010606,ECMN,-2.565000057
88337,20010607,ECMN,2.630000114
88337,20010608,ECMN,2.549999952
88337,20010611,ECMN,2.700000048
88337,20010612,ECMN,2.5
88337,20010613,ECMN,2.5
88337,20010614,ECMN,2.470000029
88337,20010615,ECMN,2.470000029
88337,20010618,ECMN,2.349999905
88337,20010619,ECMN,2.349999905
88337,20010620,ECMN,2.369999886
88337,20010621,ECMN,2.369999886
88337,20010622,ECMN,2.259999991
88337,20010625,ECMN,2.25
88337,20010626,ECMN,-2.360000134
88337,20010627,ECMN,2.25
88337,20010628,ECMN,-2.255000114
88337,20010629,ECMN,2.25

Note how 2.5 and 2.25 are represented exactly. In other cases, there is loss of precision. In sum, output from a WRDS web query may have numbers rounded up or down under certain circumstances in the formatted text output , but using either comma-delimited or tab-delimited output (or a native SAS dataset file) will show the fully stored and feasible numerical precision, where an exact value of 2.70 can not be represented precisely.

No one typed in the extra zeros and the 48, and no one believes the actual value is not 2.70. Only the computer is 'confused' and it 'saves' itself by generally treating 2.700000048 and 2.7 as equivalent.

The whole story is a complicated computer science issue that has to do with the fact that computer memory makes use of base 2 system (byte on or off ==> 0 or 1) that cannot represent every base 10 number with exact precision (using either 8 or 16 bytes of memory). In essence, mapping real numbers into computer numbers and then back to real numbers creates unavoidable rounding effects.

Here are two web links on the issue that may help

https://www.cpearson.com/excel/rounding.htm

https://docs.sun.com/source/806-3568/ncg_goldberg.html

In sum, you may be worried that either CRSP or WRDS changed the value from 2.7 to 2.700000048 by mistake. This did not happen and you can trust that what you are seeing is an inherent part of all computing, not a CRSP-WRDS issue.