6

the spaces in the constants of double precision fortran in the data records?

 2 years ago
source link: https://www.codesd.com/item/the-spaces-in-the-constants-of-double-precision-fortran-in-the-data-records.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

the spaces in the constants of double precision fortran in the data records?

advertisements

I am using the modified Bessel function dbesi0.f available in the SLATEC library.

It contains the statement:

  DATA BI0CS(  1) / -.7660547252 8391449510 8189497624 3285 D-1   /

which fills the first element of the double precision BIOCS vector.

I have never seen a double precision constant that contains spaces. The compiler does not flag this so I assume that it is correct. However, ??? A double precision vector should only be able to handle 15 or 16 digits so what is going on with the 34 digits? Are these provided in case someone is working with 128 bit numbers? If a machine is working with 64 bit double precision numbers, does the compiler only pay attention to the first xx digits in the DATA statement? If so, what is xx? Why is no error returned due to the spaces?


Note the file is fixed form source. In fixed form source spaces within statements (excluding spaces within character literals) and statement labels are not significant. Statements and statement labels just need to be contained within the right span of columns. Someone writing fixed form source can add and remove spaces outside of character literal constants to illuminate or obfuscate code to their heart's content.

(The syntax of Fortran source is consequently designed such that the compiler can parse the code without regard to spaces - for example the space between DATA and BI0CS at the start of your example snippet could be eliminated, making it DATABI0CS, or if you've got punched cards to burn it could have been written D A T A B I 0 C S. This source form feature is not generally regarded as a good thing, though it does come in handy for grouping digits in constants as per your example.)

The Fortran processor will generally use the closest internal approximation to the double precision literal constant that it can. This is not simply a case of ignoring decimal digits, because trailing decimal digits can still affect which particular internal value is closest when the radix of the processor's model for real numbers is not 10.

Providing additional precision in the source over what can be used by the Fortran processor is a form of proofing the code for use on processors that have greater numerical precision.

(The last few digits of that real literal constant make me suspect that it is intended to be an exact value at some meaningful number (possibly 64) of binary digits, but I haven't checked.)


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK