|
|
|
|
|
|
|
It is difficult to discuss this decision in terms of the C standard. The header file <float.h> largely consists of parameters of use in establishing the properties of a local execution environment and is more descriptive than prescriptive. Given the wide variety in existing machines, the situation could hardly be otherwise. |
|
|
|
|
|
|
|
|
The major potential difficulty with floating point arithmetic in general is with accuracy, which is considered in the following section. |
|
|
|
|
|
|
|
|
3.3
Precision and Accuracy |
|
|
|
|
|
|
|
|
The major concern for the SCDTL system is the adequacy of the type double for the purpose of carrying a complete date/time in the form of a Julian Day number. The answer to this question is supplied for a given system by the test programs, DTLT_047.C, DTLT_100.C, and DTLT_101.C. For PC compatibles, the answer is in the affirmative. Running these test programs may answer this question more quickly than fiddling with <limits.h> or running some of the classic tests to determine the internal accuracy of a computer. |
|
|
|
|
|
|
|
|
For all systems tested, the type double permits the Julian Day number to carry the information contained in a DATE_INFO and a TIME_INFO structure. The two forms of representation may be converted back and forth. |
|
|
|
|
|
|
|
|
In the event that a particular compiler or platform does not support this conversion correctly, all is not lost. The functions that combine a DATE_INFO structure and a TIME_INFO structure into a Julian Day number and the functions that reverse this procedure, as well as those that convert fractions to TIME_INFO structures and back again, may not be usable in this case. |
|
|
|
|
|
|
|
|
The calendar conversions, however, do not depend upon this degree of accuracy, since they are only concerned with the integer portion of the Julian Day number. Likewise, time of day can be kept separately, and the various functions that use the TIME_INFO structure remain unaffected. |
|
|
|
|
|
|
|
|
The topic of numerical analysis would take another volume, so I will only describe a few dangerous situations. |
|
|
|
|
|
|
|
|
Be aware of loss of significant digits in situations involving numbers that are nearly equal. Number of decimals is not the same as number of significant digits. The difference, for example, |
|
|
|
|
|
|
|
|
supplies a number with one significant digit, although both numbers are given to six figures. Where the two arguments have been previously rounded, the actual situation may be considerably worse. |
|
|
|
|
|
|
|
|
In practical terms, this result suggests that subtracting one JD# from another to obtain an elapsed time might not be the best approach to the problem. |
|
|
|
|
|
