Re: Time of course

• To: ethan@xxxxxxxxxxxxxxxxxx
• Subject: Re: Time of course
• From: ethan@xxxxxxxxxxxxxxxxxxxxx (Ethan Alpert)
• Date: Wed, 12 Feb 1992 22:44:54 MST

Hello again,

First this should be changed from:
>       storagevalue = 1.0 + 
>               ((idays) * (imsecsperday) * 0.00000000000000011102230246251565)
>               + (imsecs) * 0.00000000000000011102230246251565

to:

storagevalue = 1.0 +
        ((iday - 1) * (imsecperday) * 0.00000000000000011102230246251565)
        + (imsecs * 0.00000000000000011102230246251565)

Second I made the problem way too difficult I apologize.

Inaccuracies in floating point representation happen when the 52 bits of the
mantissa are not enough to represent the decimal equivalent. For decimal 
floating point this is quite easy to do when the number to represent is not a 
natural number. i.e .3 is actually 0.29999999999999998889776975374843.

However when the natural number,or integer 3 is represented in floating point
it is exact. 

In fact if only natural numbers are used then there are inaccuracies in the
representation of the numbers until you try to add 1 to 2^53 - 1.

The big question this raises concerning decodeing the float representation is,
are any significant digits lost whe the 64bit double representation of time is 
divided by some 32 bit integer like milliseconds_per_day? The integer is of
course cast to a double which should still have the same number of significant
digits.

What happens when a number with a certain number of significant digits is
divided by a number with fewer significant digits? I can't remember my freshman
physics lab where I supposedly learned this. Are the rules the same for binary 
numbers?  My guess is this would be fine only when floating point division
is used and the decimal remainder is truncated. Will using integer division
give different results? 


        -ethan