Reading MSDN, float ranges from 1E-45 to 1E38, double ranges from 1E-324 to 1E308, I am wondering why it is asymmetric for negative and positive exponents?
Asked
Active
Viewed 748 times
5 Answers
6
Your confusion stems from thinking that "1E-45" is a negative number. It is not - it is in fact a very small positive number: 1 x 10^-45 or rather, 0.000...0001 - which has 44 "0"s between the "0." and the "1"
This represents the minimum unit of accuracy that a float can store (or similar - the articles that other people have linked to will explain in detail, if you need to know).
The other number, "1E38" is an indication of the largest number that can be stored in this datatype. This is 1 x 10^38 or rather 10000...0000 i.e. 1 with 38 0s after it.
perfectionist
- 4,256
- 1
- 23
- 34
-
Now that Hans Passant has edited the question to refer to +ve and -ve exponents rather than +ve and -ve numbers, his answer is a correct and complete explanation. – perfectionist Jan 28 '12 at 17:38
1
They're not positive and negative numbers - they're positive and negative exponents. The difference is due to the way that normalization works, basically. You end up being able to store "smaller" numbers because of denormal numbers and exponent biasing.
Ultimately, you basically don't need to worry about that - but you do need to understand that the range is the same for positive and negative numbers (there's just a sign bit).
Jon Skeet
- 1,421,763
- 867
- 9,128
- 9,194
-
Anybody that cares about floating point accuracy should worry about denormals a great deal. They eat significant digits for breakfast. – Hans Passant Jan 28 '12 at 11:36
-
@HansPassant: True - but at the stage where you're not recognizing the difference between the *value* being positive and negative and the *exponent* being positive and negative, it's worth waiting a while before worrying :) – Jon Skeet Jan 28 '12 at 11:39
1
All numeric ranges for 2's complement encoding are unbalanced by design due to the presence of 0. You see this back in the .NET framework, like int.MaxValue = 2,147,483,647, int.MinValue = -2,147,483,648. This is why Math.Abs(int.MinValue) throws an exception.
The exponent of a floating point number is encoded with an offset. For float it is 8 bits with an offset of 127, providing a range of 2 ^ -126 to 2 ^ 127 or 1.18E-38 to 3.40E+38 (all mantissa bits = 1). For double it is 11 bits with an offset of 1023, 2 ^ -1022 through 2 ^ 1023 or 2.23E-308 through 1.79E+308.
The range on the bottom end is further extended by allowing a floating value to be denormal. A normalized floating point value always starts with an implicit 1, not encoded in the mantissa. When a value drops below the smallest representable value (all zeros in the mantissa, encoded exponent = 1) then the exponent is set to 0 to indicate a denormal, the implicit 1 is not there anymore. The smallest possible non-zero float has a 1 in the least significant bit of the mantissa. With 23 bits in the mantissa for a float that's 2 ^ -23 = 1.19E-7. Yielding a smallest possible value of 1.19E-7 * 1.18E-38 = 1.40E-45. The value of Single.Epsilon
You never actually want to get close to denormals, they lose significant digits in a hurry. They really only help to avert division-by-zero problems, at a price.
Hans Passant
- 922,412
- 146
- 1,693
- 2,536
0
That is due to the IEEE 754 standard which defines the coding of both (float & double). Nothing strange when you understand how it works.
Reading the article may be sufficient to understand it.
For Single precision (float) coded on 32 bits, read : http://en.wikipedia.org/wiki/Single_precision
For Double precision (double) coded on 64 bits, read : http://en.wikipedia.org/wiki/Double_precision
Good reading
Arnaud F.
- 8,252
- 11
- 53
- 102
0
I think you must be looking in the wrong place. The documentation I am looking at indicates that they are symmetrical as expected
http://msdn.microsoft.com/en-us/library/system.double.minvalue.aspx
Fur double this is positive to negative...
1.7976931348623157E+308.
ColinE
- 68,894
- 15
- 164
- 232
-
I think he is referring to: http://msdn.microsoft.com/en-us/library/678hzkk9.aspx – Magnus Jan 28 '12 at 10:32