Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

query Double precision

anupam_mu
Beginner
749 Views
hi all,

i am working on devoloping a fortran code for Even driven molecular dynamics. As it happens maintaing precision is very important.
This is my problem:
i have two variables defined as double precision x, y
is it x*y = dprod(x,y)
does the RHS is more stable in terms of precision. But i have also found that after calling the dprod function number of times overall program becomes very slow.

The second problem is that, is their any efficient way of taking substraction between two very small numbers (say of the order of 10^-7). This i also suspect can be source of error.

any suggestion is wellcome
anupam
0 Kudos
1 Reply
jimdempseyatthecove
Honored Contributor III
749 Views

Anupam

Maintaining precision while using imprecise numbers is more of an art. Look at the example from the DPROD documentation

  REAL(4) e
  REAL(8) d
  e = 123456.7
  d = 123456.7D0
  ! DPROD (e,e) returns 15241557546.4944
  ! DPROD (d,d) returns 15241556774.8899992813874268904328

What is of particular interest is the input values to the function. Note that the input value contains a decimal fraction of ".7". This fraction interestingly requires an infinite number of bits to represent as a binary fraction. Therefore both e and d are imprecise representations of the declared value. The product of two imprecise numbers tends to produce a number of bits in error equal tothe sum of the number of bits in imprecision in each variable being multiplied. Should e and d be written in different units, say in 1/10ths, then the input numbers would be 1234567, and 1234567D0 respectively. The product of these two numbers will produce an exact result with or without the use of DPROD.

Precision can be increased, depending on the dynamic range of the numbers manipulated, by changing the units of measure. Care must be taken such that intermediary results do not cause an overflow.

An additional point to consider is, for example, in the code above assume the number 123456.7 was the result of writing a calculated e from a prior program run, printed in E10.1, and was the result of a rounding operation. Initializing e to 123456.7 would not restore e to it's former value, which could never have been 123456.7.

Someone on this forum may have a recommendation as to a good book to read.

Subtracting two small numbers is not necessarily a problem. More of a problem arises from subtracting two numbers with very small differences. If these two small numbers were derived from values where you knew were A1=Base+Delta1, and A2=Base+Delta2, and you removed Base from each prior to the subtraction then the effect is that your intention is to produce the difference of two small numbers but in actuality you are taking the difference of two numbers with very small differences. Precision may have been lost.

When reading the above paragraph that there is somewhat a dichotomy between the spoken words (infinite precision) and the computational performance (finite precision).

Jim Dempsey

0 Kudos
Reply