## jmol-users

 [Jmol-users] TechNote: floating point representations From: Miguel - 2004-04-14 09:20:45 ```Someone raised the following issue which I thought would be of general interest. Regarding the display of crystal cell parameters: > In a few cases the a, b, or c etc values display with 'extra' decimal > places > > the 10pre8 applet displays a=10.436999 wheas the CRYST1 record of the pdb > file has the value 10.437. Presumably a 'rounding' anomaly with the cell > coordinate calculations. Actually, this particular case is a more subtle issue. It wasn't really a 'rounding' issue because no calculations were performed on the number. But the source of this *problem* is of general interest to those who work with floating point numbers. We are used to working in base 10 ... 10 fingers. From time-to-time we come across rational numbers which cannot be represented in base 10. The simplest examples are 1/3 and 2/3. We write them as 0.33 or 0.67, or extend them out a few more digits (0.33333 0.66667) if we need more accuracy in our calculations. Well, we run across the same issue in the computer world. And people have been struggling with ways to address this issue since the beginning of digital computers. Most computers today generally use a floating point representation defined in 1985 by the IEEE standards organization: IEEE Std 754-1985 IEEE Standard for Binary Floating-Point Arithmetic This is a 'base 2' (binary) representation of floating point numbers, not a 'base 10' representation. Fundamentally, this means that there is a different set of rational numbers which cannot be accurately represented. In this case, no calculations were performed on the number 10.437 ... it was read straight out of the file. But the number 10.437 cannot be accurately represented in binary ... so we end up with 10.436999 (I haven't actually verified this, but I assume it is the case). Other random facts: * COBOL supported decimal and fixed-point numbers to address this issue in a business environment * one of the representations on IBM mainframes was base 16 (instead of base 2) While this did not address this particular issue, it did provide faster performance (during the 'normalizing' process) * People who want high performance generally do not follow the IEEE standard. * The initial Java Virtual Machine specification *required* IEEE representation (and operational behavior) for floating point numbers. This (should) ensure portability across platforms ... the same calculation should give you the same answer on different systems. This requirement has since been relaxed somewhat ... to allow higher-performance computing ... and because of the recognition that it is an unsolvable problem. * I think that most people agree that the IEEE standard has errors, but people must follow it * Systems for doing symbolic/pure math (Mathematica, MATLAB, Macsyma) support rational numbers (fractional representation of integers ... 1/3, 2/3) to try to avoid this type of problem for _rational_ numbers. Miguel ```