Just for reference. IEEE defines a 64 bit double to have one sign bit, 11
exponent bits and 52 mantissa bits. There is also an implied "sticky bit"
which is always set to 1 and is assumed to be left of the decimal point.
There are three special values of the exponent; all zeros represents exact
zero and all ones being used to represent +- infinity
My confusion stems from not understanding how you plan to use the 52 bit IEEE
mantissa as a 52 bit integer. I understand that you simply have to use the
LSB to advance the time counter but how are you going to disable the floating
point of the machine, so as to prevent the machine from using the exponent part
of the IEEE double.
For example what if I start at the base (I'm assuming the base will start
with
the mantissa set to all zeros and the exponent zeroed too). The decimal value
of this number would be 0.0. When the exponent is all zeros then the number
represents exact zero.
Now lets say I'm creating the coordinate variable and I start with the above
conditions. The first element gets the 0.0 value. For the second value I add
the LSB value to it. Here is the first hint of the problem. When I perform
this addition the mantissa is UNCHANGED and the exponent represents 2^-52. This
could be 2^-53 I'm not certain but my point should be evident. In some cases
equal mantissas could represent different coordinate time values.
Is this clear? I think this is what concerns Dan.
The answer is to start the base at 1.0 and add multiples of the LSB to it
to
compute the values to store in the coordinate variable. This works because
IEEE has the "sticky bit" that is always set and the binary number would look
something like the following.
1.0000000000....1
^ ^
Sticky bit LSB
It is important to note that one can only add to and subtract from the base.
Multiplication and Division must not be used because the CPU will use set the
exponent of the double. Furthermore, when computing multiples of the LSB to
add to the base only integer mulipliers should be used. This seems like a lot
to require the average user to know, remember and think about.
Finally, if I want to select the first 10 milliseconds of June 1st for a ten
year period from within my own application how would I do this. The conversion
from the floating point representation would appear to be kind of mind twisting,
when taking into account leap years and irregular month spacing. How will
generic applications handle this? More discussion is needed on accesing time
data once its stored in the NC_DOUBLE format? Can a conversion utility library
be developed to handle this?
-ethan