|
|
You're in the
dotnet clr
group:Decimal Data Type bit layout
dotnet clr:
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.
Hi
We have reviewed this issue and are currently researching on it. We will update you ASAP. Thanks for your patience! Kevin Yu ======= "This posting is provided "AS IS" with no warranties, and confers no rights."
[quoted text, click to view]
mdavidjohnson <mdj@nospam.nospam> wrote: > 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. 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. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet
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. [quoted text, click to view] "Jon Skeet [C# MVP]" wrote:
> mdavidjohnson <mdj@nospam.nospam> wrote: > > 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. > > 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. > > -- > Jon Skeet - <skeet@pobox.com> > http://www.pobox.com/~skeet > If replying to the group, please do not mail me too
Sorry, I meant 11-bit exponent (I've got floats, doubles, and decimals all
swirling around in my head at the moment) [quoted text, click to view] "Jon Skeet [C# MVP]" wrote:
> mdavidjohnson <mdj@nospam.nospam> wrote: > > 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. > > 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. > > -- > Jon Skeet - <skeet@pobox.com> > http://www.pobox.com/~skeet > If replying to the group, please do not mail me too
[quoted text, click to view]
mdavidjohnson <mdj@nospam.nospam> wrote: > 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. 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. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet
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. [quoted text, click to view] "mdavidjohnson" <mdj@nospam.nospam> wrote in message news:782F5053-58FA-4206-BD72-110AA28342A7@microsoft.com... > Sorry, I meant 11-bit exponent (I've got floats, doubles, and decimals all > swirling around in my head at the moment) > > "Jon Skeet [C# MVP]" wrote: > >> mdavidjohnson <mdj@nospam.nospam> wrote: >> > 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. >> >> 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. >> >> -- >> Jon Skeet - <skeet@pobox.com> >> http://www.pobox.com/~skeet >> If replying to the group, please do not mail me too >>
"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> writes:
[quoted text, click to view] > 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. 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 -- Department of Natural Sciences http://www.dina.kvl.dk/~sestoft/ Royal Veterinary and Agricultural University * Tel +45 3528 2334
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 Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |