for example:
const decimal dollars = 25.50M;
why do we have to add that M?
why not just do:
const decimal dollars = 25.50;
since it already says decimal, doesnt it imply that 25.50 is a decimal?
No.
25.50 is a standalone expression of type double, not decimal.
The compiler will not see that you're trying to assign it to a decimal variable and interpret it as a decimal.
Except for lambda expressions, anonymous methods, and the conditional operator, all C# expressions have a fixed type that does not depend at all on context.
Imagine what would happen if the compiler did what you want it to, and you called Math.Max(1, 2).
Math.Max has overloads that take int, double, and decimal. Which one would it call?
There are two important concepts to understand in this situation.
Literal Values
Implicit Conversion
Essentially what you are asking is whether a literal value can be implicitly converted between 2 types. The compiler will actually do this for you in some cases when there would be no loss in precision. Take this for example:
long n = 1000; // Assign an Int32 literal to an Int64.
This is possible because a long (Int64) contains a larger range of values compared to an int (Int32). For your specific example it is possible to lose precision. Here are the drastically different ranges for decimal and double.
Decimal: ±1.0 × 10−28 to ±7.9 × 1028
Double: ±5.0 × 10−324 to ±1.7 × 10308
With knowledge it becomes clear why an implicit conversion is a bad idea. Here is a list of implicit conversions that the C# compiler currently supports. I highly recommend you do a bit of light reading on the subject.
Implicit Numeric Conversions Table
Note also that due to the inner details of how doubles and decimals are defined, slight rounding errors can appear in your assignments or calculations. You need to know about how floats, doubles, and decimals work at the bit level to always make the best choices.
For example, a double cannot precisely store the value 25.10, but a decimal can.
A double can precisely store the value 25.50 however, for fun binary-encoding reasons.
Decimal structure
Related
Example:
float timeRemaining = 0.58f;
Why is the f is required at the end of this number?
Your declaration of a float contains two parts:
It declares that the variable timeRemaining is of type float.
It assigns the value 0.58 to this variable.
The problem occurs in part 2.
The right-hand side is evaluated on its own. According to the C# specification, a number containing a decimal point that doesn't have a suffix is interpreted as a double.
So we now have a double value that we want to assign to a variable of type float. In order to do this, there must be an implicit conversion from double to float. There is no such conversion, because you may (and in this case do) lose information in the conversion.
The reason is that the value used by the compiler isn't really 0.58, but the floating-point value closest to 0.58, which is 0.57999999999999978655962351581366... for double and exactly 0.579999946057796478271484375 for float.
Strictly speaking, the f is not required. You can avoid having to use the f suffix by casting the value to a float:
float timeRemaining = (float)0.58;
Because there are several numeric types that the compiler can use to represent the value 0.58: float, double and decimal. Unless you are OK with the compiler picking one for you, you have to disambiguate.
The documentation for double states that if you do not specify the type yourself the compiler always picks double as the type of any real numeric literal:
By default, a real numeric literal on the right side of the assignment
operator is treated as double. However, if you want an integer number
to be treated as double, use the suffix d or D.
Appending the suffix f creates a float; the suffix d creates a double; the suffix m creates a decimal. All of these also work in uppercase.
However, this is still not enough to explain why this does not compile:
float timeRemaining = 0.58;
The missing half of the answer is that the conversion from the double 0.58 to the float timeRemaining potentially loses information, so the compiler refuses to apply it implicitly. If you add an explicit cast the conversion is performed; if you add the f suffix then no conversion will be needed. In both cases the code would then compile.
The problem is that .NET, in order to allow some types of implicit operations to be carried out involving float and double, needed to either explicitly specify what should happen in all scenarios involving mixed operands or else allow implicit conversions between the types to be performed in one direction only; Microsoft chose to follow the lead of Java in allowing the direction which occasionally favors precision, but frequently sacrifices correctness and generally creates hassle.
In almost all cases, taking the double value which is closest to a particular numeric quantity and assigning it to a float will yield the float value which is closest to that same quantity. There are a few corner cases, such as the value 9,007,199,791,611,905; the best float representation would be 9,007,200,328,482,816 (which is off by 536,870,911), but casting the best double representation (i.e. 9,007,199,791,611,904) to float yields 9,007,199,254,740,992 (which is off by 536,870,913). In general, though, converting the best double representation of some quantity to float will either yield the best possible float representation, or one of two representations that are essentially equally good.
Note that this desirable behavior applies even at the extremes; for example, the best float representation for the quantity 10^308 matches the float representation achieved by converting the best double representation of that quantity. Likewise, the best float representation of 10^309 matches the float representation achieved by converting the best double representation of that quantity.
Unfortunately, conversions in the direction that doesn't require an explicit cast are seldom anywhere near as accurate. Converting the best float representation of a value to double will seldom yield anything particularly close to the best double representation of that value, and in some cases the result may be off by hundreds of orders of magnitude (e.g. converting the best float representation of 10^40 to double will yield a value that compares greater than the best double representation of 10^300.
Alas, the conversion rules are what they are, so one has to live with using silly typecasts and suffixes when converting values in the "safe" direction, and be careful of implicit typecasts in the dangerous direction which will frequently yield bogus results.
In Single struct and Decimal struct document at Ms Docs that says about type conversion from Decimal to Single, the former says it's widening conversion and latter says it's narrowing conversion. Which one is right?
And I don't get how the magnitude of the Decimal type could be preserved when converted to Single type. Please explain.
Strictly speaking, conversion from Decimal to Single is neither narrowing nor widening. Decimal has a narrower range than a Single but it has a wider precision.
Conversion from Decimal to Single will never throw an OverflowException but it can lead to a loss of information. That is why there is no Implicit conversion in either direction.
The range of a Single is ±1.5 x 10−45 to ±3.4 x 1038 compared to the range of a Decimal of ±1.0 x 10−28 to ±7.9228 x 1028. So both the smallest possible Decimal and the largest possible Decimal can fit in a Single without overflow. The magnitude of the Decimal will be maintained.
However, the precision of a Single is only around 6-9 digits (in base 10) compared to 28-29 digits in a Decimal. So if you convert a Decimal to a Single, any of the digits after the sixth-ninth will be lost. There is a potential loss of information, but not a loss of the magnitude of the number.
More Information
You ask how it is possible that the magnitude of a Decimal stored in 12 bytes can fit in a Single of only 4 bytes. The reason is that decimal/floating point numbers are not stored as a direct conversion to binary - part of the storage is used for the magnitude (like the "times 10 to the power of" in scientific format) and part is used for the binary equivalent of the digits themselves.
I'm attempting to truncate a series of double-precision values in C#. The following value fails no matter what rounding method I use. What is wrong with this value that causes both of these methods to fail? Why does even Math.Round fail to correctly truncate the number? What method can be used instead to correctly truncate such values?
The value :
double value = 0.61740451388888251;
Method 1:
return Math.Round(value, digits);
Method 2:
double multiplier = Math.Pow(10, decimals)
return Math.Round(value * multiplier) / multiplier;
Fails even in VS watch window!
Double is a floating binary point type. They are represented in binary system (like 11010.00110). When double is presented in decimal system it is only an approximation as not all binary numbers have exact representation in decimal system. Try for example this operation:
double d = 3.65d + 0.05d;
It will not result in 3.7 but in 3.6999999999999997. It is because the variable contains a closest available double.
The same happens in your case. Your variable contains closest available double.
For precise operations double/float is not the most fortunate choice.
Use double/float when you need fast performance or you want to operate on larger range of numbers, but where high precision is not required. For instance, it is perfect type for calculations in physics.
For precise decimal operations use, well, decimal.
Here is an article about float/decimal: http://csharpindepth.com/Articles/General/FloatingPoint.aspx
If you need a more exact representation of the number you might have to use the decimal type, which has more precision but smaller range (it's usually used financial calculations).
More info on when to use each here: https://stackoverflow.com/a/618596/1373170
According to this online tool which gives the binary representation of doubles, the two closest double values to 0.62 are:
6.19999999999999995559107901499E-1 or 0x3FE3D70A3D70A3D7
link
6.20000000000000106581410364015E-1 or 0x3FE3D70A3D70A3D8
link
I'm not sure why neither of these agree with your value exactly, but like the others said, it is likely a floating point representation issue.
I think you are running up against the binary limit of a double-precision float (64 bits). From http://en.wikipedia.org/wiki/Double-precision_floating-point_format, a double only gives between 15-17 significant digits.
As a follow up to the question what is the purpose of double implying...
Also, I read in an article a while back (no I don't remember the link) that it is inappropriate to do decimal dollars = 0.00M;. It stated that the appropriate way was decimal dollars = 0;. It also stated that this was appropriate for all numeric types. Is this incorrect, and why? If so, what is special about 0?
Well, for any integer it's okay to use an implicit conversion from int to decimal, so that's why it compiles. (Zero has some other funny properties... you can implicitly convert from any constant zero expression to any enum type. It shouldn't work with constant expressions of type double, float and decimal, but it happens to do so in the MS compiler.)
However, you may want to use 0.00m if that's the precision you want to specify. Unlike double and float, decimal isn't normalized - so 0m, 0.0m and 0.00m have different representations internally - you can see that when you call ToString on them. (The integer 0 will be implicitly converted to the same representation as 0m.)
So the real question is, what do you want to represent in your particular case?
In c# when you want to divide the result of a method such as below, what is the best way to force it to return a double value rather than the default integer.
(int)Math.Ceiling((double)(System.DateTime.DaysInMonth(2009, 1) / 7));
As you can see I need the division to return a double so I can use the ceiling function.
A division of two int numbers returns an int, truncating any decimal points. This is generally true for other data types as well: arithmetic operations don't change the type of their operands.
To enforce a certain return type, you must therefore convert the operands appropriately. In your particular case, it's actually sufficient to convert one of the operators to double: that way, C# will perform the conversion for the other operand automatically.
You've got the choice: You can explicitly convert either operand. However, since the second operand is a literal, it's better just to make that literal the correct type directly.
This can either be done using a type suffix (d in the case of double) or to write a decimal point behind it. The latter way is generally preferred. in your case:
(int)Math.Ceiling(System.DateTime.DaysInMonth(2009, 1) / 7.0);
Notice that this decimal point notation always yields a double. To make a float, you need to use its type suffix: 7f.
This behaviour of the fundamental operators is the same for nearly all languages out there, by the way. One notable exception: VB, where the division operator generally yields a Double. There's a special integer division operator (\) if that conversion is not desired. Another exception concerns C++ in a weird way: the difference between two pointers of the same type is a ptrdiff_t. This makes sense but it breaks the schema that an operator always yields the same type as its operands. In particular, subtracting two unsigned int does not yield a signed int.
Change the 7 to a double:
(int) Math.Ceiling(System.DateTime.DaysInMonth(2009, 1) / 7.0);
just divide with a literal double:
(int)Math.Ceiling((System.DateTime.DaysInMonth(2009, 1) / 7.0))
As far as I know, you can't force a function to return a different type, so casting the result is your best bet. Casting the result of the function to a double and then dividing should do the trick.
To expand upon Konrad's answer...
Changing 7 to 7.0, 7 to 7D, 7 to 7M all get you the answer you want as well.
For a completely different approach that avoids casting and floating-point math altogether...
int result = val1 / val2;
if (val1 % val2 != 0) result++;
So, in your case...
int numDaysInMonth = System.DateTime.DaysInMonth(2009, 1);
int numWeeksInMonth = numDaysInMonth / 7;
if (numDaysInMonth % numWeeksInMonth != 0) numWeeksInMonth++;
This approach is quite verbose, but there might be some special cases where it is preferable. Technically, there should be a slight performance advantage to the modulus approach, but you'll be hard-pressed to measure it.
In your case, I'd stick with the accepted answer :-)