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 timetotime 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 7541985
IEEE Standard for Binary FloatingPoint 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 fixedpoint 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
higherperformance 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
