 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / September 2005Decimal Data Type bit layout
What is the actual bit layout of the decimal data type? i.e.; if the double data type layout is sign = 1 bit, biased exponent = 11 bits, and mantissa = 52 bits; what is the corresponding description for decimal? I read that a decimal includes a 1-bit sign, a 96-bit integer number, and an exponent that ranges from 0 to 28 (which would require 5 bits). The total would thus be 102 bits which would fit in 13 bytes with two bits left over. Seems strange. Hi We have reviewed this issue and are currently researching on it. We will update you ASAP. Thanks for your patience! Kevin Yu  Signature======= "This posting is provided "AS IS" with no warranties, and confers no rights." > What is the actual bit layout of the decimal data type? > [quoted text clipped - 6 lines] > would thus be 102 bits which would fit in 13 bytes with two bits left over. > Seems strange. That's exactly the layout - if you look at the docs for Decimal, it's documented there. I suspect the reason it doesn't go any further is that it's a lot easier (and quicker) to manipulate three ints as the mantissa than "three and a bit" ints. I suspect there aren't many applications for which 28 digits is insufficient, but a couple more digits would be okay. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Thanks Jon, I didn't express my question as clearly as I should have. What I'm really looking for is an indication of how the bits are laid out in a field of bytes. For example, a double is laid out in a field of 8 bytes with the sign bit at the high end, followed by the 8-bit exponent, which is followed by the 52-bit mantissa at the low end; all stored in little endian order. If the decimal type is really laid out in 13 bytes, where are the extra two bits positioned? I need this information so I can handle decimal types in assembly language in a DLL. > > What is the actual bit layout of the decimal data type? > > [quoted text clipped - 15 lines] > which 28 digits is insufficient, but a couple more digits would be > okay. > I didn't express my question as clearly as I should have. > [quoted text clipped - 9 lines] > I need this information so I can handle decimal types in assembly language > in a DLL. Look at Decimal.GetBits - there are 12 bytes of mantissa, then the last four bytes contain 2 zero bytes, one byte with the exponent, and one byte with just the sign. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Hi MDJ, Does the community's replies make sense to you? If you still have any concern, please feel free ot feedback. Thanks Best regards, Jeffrey Tan Microsoft Online Partner Support SignatureGet Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights. Sorry, I meant 11-bit exponent (I've got floats, doubles, and decimals all swirling around in my head at the moment) > > What is the actual bit layout of the decimal data type? > > [quoted text clipped - 15 lines] > which 28 digits is insufficient, but a couple more digits would be > okay. The exact lay-out in BCL 32 bit flags 32 bit word high 32 bit word low 32 bit word mid So 96 bits representing the number. flags represent the scale and the sign, as follows: 31----24 - sign - number is negative when bit 31 = 1 (only one bit used) 23----16 - scale bits - number of decimal places (valid range 0-28, 5 bits used) fi. 12.365 is represented a 12365 with scale 3 remaining bits of flags are not used. Willy. > Sorry, I meant 11-bit exponent (I've got floats, doubles, and decimals all > swirling around in my head at the moment) [quoted text clipped - 22 lines] >> which 28 digits is insufficient, but a couple more digits would be >> okay. > The exact lay-out in BCL > [quoted text clipped - 11 lines] > fi. 12.365 is represented a 12365 with scale 3 > remaining bits of flags are not used. This is the current Microsoft layout for decimal. The third edition of the Ecma standard for CLI (2005) does not specify the layout. The reason is that Mike Cowlishaw at IBM UK has designed a clever representation that offers more precision (34 decimal digits) and a much larger exponent range (+/- 6134) within the same 128 bits. This is likely to become the IEEE standard for decimal, and it is conceivable that Microsoft will adopt this representation at some point. So for long-term portability, externally stored decimals should be represented as strings rather than bit patterns. Peter SignatureDepartment of Natural Sciences http://www.dina.kvl.dk/~sestoft/ Royal Veterinary and Agricultural University * Tel +45 3528 2334 Thorvaldsensvej 40, DK-1871 Frederiksberg C, Denmark * Fax +45 3528 2350
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.