[dba-Tech] Conversion of REAL decimal numbers to Hex

Marty,

Thanks for the excellent technical description.  On the demo web site
for the hex conversion there's a breakdown into those three segments
you mentioned, so one can see how it's divvied up.

I am intensely curious as to whether the Virtual Calc 2000 routines
are callable in VBA.  When you consider that Long Integers only go up
to 2^20, and that functions like Mod are limited to numbers of that
size, too, the achievement of folks like Po-Han Lin and Stephen
Wolfram is even more marvelous.

I'd love to be able to call a routine that would, say, convert a
string of text (in base 62, say) to base 36 after multiplying by pi to
100 decimal places.  The only way that Access could handle numbers of
that size, of course, would be as strings...but that would be more
than adequate if it could just be done as a function call.

Mr. Po-Han's calculator is really something.  I'm going to buy the
shareware version so that I can directly manipulate scientific
notation.  I intend to write to him to find out about whether he has a
DLL available with those fabulous functions.

Steve Erbach
http://TheTownCrank.blogspot.com


On 3/21/06, MartyConnelly <martyconnelly at shaw.ca> wrote:
> There is no decimal point. It is implied.
> Double Floating Point numbers are encoded by IEEE 754 for MS
> 1 bit sign (high order bit) really part of exponent by normalization
> 11 bit exponent
> 53 bit mantissa
> However Intel FPU registers can handle 80 bits but that's another story
> for bedtime.
>
> 3FF is 1023 or 1 less than 1024 so there maybe some exponent bias to
> handle negative numbers and exponent
> for 32 bit  exponent bias is =127 or 7F  approx 2^7 so needs 7 bits and
> 1 sign bit storage
>
> This is where it gets weird and has to be groked otherwise read the IEEE
> 754 floating point standard
>
>  The bias of the exponent.  Usually some fixed integer (typically
> 127 or 128 for an 8-bit exponent) is added to the exponent as a
> "bias", since an exponent of all zero bits usually is reserved to
> represent the number zero, which must be treated as a special case
> since it cannot, like non-zero numbers, be represented as a
> normalized floating-point number (a "normalized" f.p. number has a
> most significant mantissa digit that's non-zero; if the most
> significant mantissa digit is zero, the number is normalized by
> shifting the mantissa left one digit while decreasing the exponent by
> one, and repeating until either the most significant mantissa digit
> becomes non-zero or until the exponent reaches its smallest possible
> value, whichever comes first.  Since the number zero has all mantissa
> digits zero, it cannot be normalized).
> . The representation of the sign of the mantissa. Keeping the sign
> in a separate sign bit, is called the  sign-magnitude representation
>  and seems to be the most common representation today.
>   Other, less common, representations is to use either ones-complement or
>  twos-complement representation of the entire mantissa.
>
>  If the mantissa is represented in binary normalized form, the most
> significant bit will always be one (unless the the entire number is
> zero) - therefore this bit need not be stored but can be implicit.
> The IEEE 32-bit and 64-bit floating-point formats does not store this
> bit.  Other formats (e.g. the 80-bit "extended IEEE" format used in
> Intel x86 FPU's) does explicitly store the most significant mantissa
> bit.  IEEE 854  double-extended-precision format (1 sign bit, 15
> exponent bits,
>  16 empty bits, 64 mantissa bits).
>
> Now if you think this is weird try it on a 36 bit word mainframe.
>
>
>