|
|
|
|
|
|
|
Trigonometric functions are often implemented carelessly. It is not unusual to find over half of the decimals given by a sine function to be in error. An application that uses trigonometric functions should exercise caution. |
|
|
|
|
|
|
|
|
Rounding is inevitable when performing calculations on a computer. Do not be terribly concerned if answers vary in the last decimal place or so from those published in this book. Be aware, however, that rounding errors may accumulate. In many applications errors tend to cancel each other, whereas in other applications they can increase (almost) without bound. The SCDTL routines avoid these situations, but it is certainly possible to write applications that do not. Error accumulation generally occurs in situations where a loop replaces a variable with a modified value of itself, and the error is allowed to increase monotonically. As an example, consider "Test 1" in the DTLT_146.C program. Use this test program to get a feel for the accuracy of the system in use. "Test 2" in this program should yield a value close to 674530.4707 . "Test 3" will supply a quick measure of the number of mantissa bits carried by the type double on a system and report the equivalent number of significant decimal digits. A 64-bit mantissa is equivalent to a few more than 19 digits. |
|
|
|
|
|
|
|
|
Note that the SCDTL system, in those situations where calculations must accumulate elapsed time, resorts to using integer units in the native counting system of the calendar in question, even where this is not computationally efficient. The use of integer units avoids rounding errors that would otherwise accumulate if the native units were converted to floating point units. |
|
|
|
|
|
|
|
|
3.4
Options and Alternatives |
|
|
|
|
|
|
|
|
The design decisions used for the SCDTL system are, in almost every instance, the result of compromise. A general rule was followed, which dictated that inefficiency would be accepted at a lower level if consistency through the system overall were enhanced. |
|
|
|
|
|
|
|
|
In several cases, alternative implementations of data structures could be considered. Some are: |
|
|
|
|
|
|
|
|
The Julian Day number could be split into two type double variables, with one dedicated to the fractional part. This solution does not accomplish anything, except to create the need for a structure for the Julian Day number, since it does not actually purchase any significant digits. |
|
|
|
|
|
|
|
|
In a slightly different approach, the Julian Day number could be kept as one type long for the integer portion and a type double for the fractional part. Since the calendar conversion routines use a JD0, which ignores the fractional part, and frequently convert to type long for internal use anyway, this argument may be considered. |
|
|
|
|
|