MartyConnelly
martyconnelly at shaw.ca
Tue Mar 21 16:27:29 CST 2006
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. Steve Erbach wrote: >Josh, > >I hear you on the cutoff. I tried converting by hand the decimal >number 1.07 to hex and got 1.11EB85 before I stopped. > >I did find an on-line calculator: > >http://babbage.cs.qc.edu/courses/cs341/IEEE-754.html > >Apparently, there's a standard way to represent floating point numbers >in hex, but the resulting Hex number doesn't have a "decimal" point. >For example, 1.07 (decimal) comes out as 3FF11EB851EB851F using a >64-bit double precision hex number. You can see the string "11EB85" >in that number, the same that I came up with manually, but I'm still >puzzling over the beginning 3FF. > >The site has the complete JavaScript code for the conversion, so maybe >I can figure out what the 3FF is for. > >Thanks, > >Steve Erbach >http://TheTownCrank.blogspot.com > > >On 3/21/06, Josh McFarlane <darsant at gmail.com> wrote: > > >>On 3/21/06, Steve Erbach <erbachs at gmail.com> wrote: >> >> >>>Dear Group, >>> >>>There are about a jillion decimal to hex converters on the web. But >>>what I'm looking for is a converter that will handle decimal numbers >>>with decimals. That is, convert 1.0625 (decimal) to 1.1 >>>(hexadecimal). I can write one that recursively takes the remainder >>>from a division by higher and higher powers of 16 and dividing the >>>remainder the the next higher power of sixteen, etc. Just wondered if >>>any of you had seen such a utility. >>> >>> >>Are you looking for something for integration into a system, or >>something for personal use? >> >>Problem with trying to represent a floating decimal based number in a >>different system is that you can't always get an exact value for the >>number you want to represent, so any cnoversion utility would have to >>have a cutoff point. >> >>I've tinkered with a C++ app to do it for me, but it's not anywhere >>near professional, just a toy. >> >>-- >>Josh McFarlane >> >> >_______________________________________________ >dba-Tech mailing list >dba-Tech at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-tech >Website: http://www.databaseadvisors.com > > > > -- Marty Connelly Victoria, B.C. Canada