problems with real number

[lukadiz]

Hi, I'm a new utent in this forum and I'm going to use Intel fotran compiler to realize a subroutine with uses 2 numerical inputs and return a real number very small..I just start to use a complier..so excuse me if my problem could be banal..I use windows XP professional, Intel fortran 11.0 (evaluation version)..I define all real variable with DOUBLE PRECISION..but results lose precision after the 8thterm after thecomma...I think the problem could be in the compile settings..can someone help me?!...where I can modify this settings?!...can I madufy these settings throught the prompt of windows?!
luca

[TimP]

If you take the difference of double precision numbers which are equal in the first 7 decimal significant figures, your result, as you say, retains at most 8 decimal significant figures. ifort supports real*16, at great cost in performance, in case that is interesting.
If you do arithmetic on double precision numbers of magnitude 1e-300, again you have at most 8 signficant decimal digits, unless you set options including /Qftz-. /fp:source will take care of that, extending numerical range down to 1e-323, at some cost in performance. /arch:ia32, for the 32-bit ifort, gives you even more range at more cost in performance.

[jimdempseyatthecove]

lukadiz,

Some consideration should be made when programming such that you reduce the potential for loss in information when manipulating large and small data.

Example:

You have a vibration test being performed on a satellite.

Case 1:Base your displacement measurements relative to the center of Earth.
Case 2: Base your displacement measurements relative to average and relative center of mass of the satellite.
Case 3: Base your displacement measurements relative to a component on your test equipment.

What you base your measurements on do not affect the movement of the object under test.
What you base your measurements on does affect the required dynamic range of the numbers required to attain equivilent precision ofresults.

Case 1 might require REAL(16), case 2 might require REAL(8), case 3 might get by with REAL(4).

As someone else on the forum mentioned (wish I could recall their name) if you wish to perform something simple on data sets containing large and small numbers (relative to each other) sequencing does matter. Example, to sum an array of these types of data you would get better results by sorting the values in ascending order then perform the sum processing the list in sorted order. If you do not want to take the time to perform the sort you could perform the summation using some sort of non-roundingfencing operation such as using

WHOLE_SUM = 0.0_8
FRAC_SUM = 0.0_8
DO I=1,COUNT
WHOLE = AINT(ARRAY(I))
FRAC =ARRAY(I)- WHOLE
WHOLE_SUM = WHOLE_SUM+ WHOLE
FRAC_SUM = FRAC_SUM + FRAC
END DO
SUM_SUM = WHOLE_SUM + FRAC_SUM

As an alternate approach you could also hold your data with a bias. In the vibration test, if you want to use distance from center of Earth but also know that the orbital path will never fall below 300KM all your data could be held with a bias of -300KM. Doing this "compresses" inconsiquential data.

Attention to details like this will produce better results.

Jim Dempsey