Develop Reference

Is it safe to cast Math.Round result to float?

A colleague has written some code along these lines:
var roundedNumber = (float) Math.Round(someFloat, 2);
Console.WriteLine(roundedNumber);
I have an uncertainty about this code - is the number that gets written here even guaranteed to have 2 decimal places any more? It seems plausible to me that truncation of the double Math.Round(someFloat, 2) to float might result in a number whose string representation has more than 2 digits. Can anybody either provide an example of this (demonstrating that such a cast is unsafe) or else demonstrate somehow that it is safe to perform such a cast?

Assuming single and double precision IEEE754 representation and rules, I have checked for the first 2^24 integers i that
float(double( i/100 )) = float(i/100)
in other words, converting a decimal value with 2 decimal places twice (first to the nearest double, then to the nearest single precision float) is the same as converting the decimal directly to single precision, as long as the integer part of the decimal is not too large.
I have no guarantee for larger values.
The double approximation and the single approximation are different, but that's not really the question.
Converting twice is innocuous up to at least 167772.16, it's the same as if Math.Round would have done it directly in single precision.
Here is the testing code in Squeak/Pharo Smalltalk with ArbitraryPrecisionFloat package (sorry to not exhibit it in c# but the language does not really matter, only IEEE rules do).
(1 to: 1<<24)
detect: [:i |
(i/100.0 asArbitraryPrecisionFloatNumBits: 24) ~= (i/100 asArbitraryPrecisionFloatNumBits: 24) ]
ifNone: [nil].
EDIT
Above test was superfluous because, thanks to excellent reference provided by Mark Dickinson (Innocuous double rounding of basic arithmetic operations) , we know that doing float(double(x) / double(y)) produces a correctly-rounded value for x / y, as long as x and y are both representable as floats, which is the case for any 0 <= x <= 2^24 and for y=100.
EDIT
I have checked with numerators up to 2^30 (decimal value > 10 millions), and converting twice is still identical to converting once. Going further with an interpreted language is not good wrt global warming...

c# calculation only returns natural number instead of decimal [duplicate]

When I make a division in C#, it automaticaly rounds down. See this example:
double i;
i = 200 / 3;
Messagebox.Show(i.ToString());
This shows me a messagebox containing "66". 200 / 3 is actually 66.66666~ however.
Is there a way I can avoid this rounding down and keep a number like 66.6666667?

i = 200 / 3 is performing integer division.
Try either:
i = (double)200 / 3
or
i = 200.0 / 3
or
i = 200d / 3
Declaring one of the constants as a double will cause the double division operator to be used.

200/3 is integer division, resulting in an integer.
try 200.0/3.0

200 / 3 this is an integer division. Change to: 200.0 / 3 to make it a floating point division.

You can specify format string with the desired number of decimal ponits:
double i;
i = 200 / 3.0;
Messagebox.Show(i.ToString("F6"));

Though the answer is actually 66.666, what is happening is that 200 / 3 is being calculated resulting in an integer. The integer is then being placed in the float. The math itself is happening as integer math. To make it a float, use 200.0 / 3. The .0 will cause it to treat 200 as a float, resulting in floating point math.

Aside from the double vs int happening in that action, you're thinking of double as a precise unit. Try using the decimal datatype when you really care about accuracy.
More information at this answer:
decimal vs double! - Which one should I use and when?

double i = 200.0 / 3;
double i = ((double)200)/3;
What happens is the two integers perform an integer divide, and then the integer answer is assigned to the float. To avoid that, always cast one of the numbers as a double.

Try this
i = 200d/3d;
and it will not round.

200 and 3 are both integers, so the result will be an integer. Convert one of them to a decimal.

All given answers are wrong because they translate the integer division into one of kind double, which is cleanly not what was asked for (at least from a performance standpoint). The obvious answer is elementary school math, multiply by 10, add 5 and divide again, all integer.
i = (2000 / 3 + 5 ) / 10
You are catching a second division here, which is better than doing double conversions but still far from perfect. You could go even further and multiply by another factor and add other values than five, thus allowing you to use right shifting instead of dividing by 10. The exact formula for doing this is left as an exercise to the reader. (Just google "divisions with Multiply Shift")
Have a nice day.

A simple C# Statement works unexpected

I've got this line of code:
int WStoneCost = PriceMethod.StoneCost / 100 * AP;
While PriceMethod.StoneCost is equal to 25 and AP is equal to 70.
I've checked it using breakpoints and I can't understand why do I get zero after I run this line. (WStoneCost is equal to zero)
Is it just a wrong symbol or am I doing something wrong? Thanks in advance.
And how to get a correct double at the end? Like 17.5

You are doing integer division, so 25/100 is 0, not 0.25, and hence 0 * 70 is 0. Since your result variable is also an int it's unclear what result you are expecting, but you could reorder the operations to get a non-zero answer:
int WStoneCost = (PriceMethod.StoneCost * AP)/ 100 ;
It's still integer division, but with your inputs will divide 25*70 (1,750) by 100, which will give you 17.
If you want a floating-point decimal result, just use 100m:
decimal WStoneCost = (PriceMethod.StoneCost * AP)/ 100m ;
Since the literal 100m is a decimal, then the compiler will use floating-point decimal division, which will give you a decimal result.

And how to get a correct double at the end? Like 17.5
Your question and both of the two answers given so far indicate that all three of you want to do something dangerously wrong. You are doing financial calculations so you should always be using decimal, never double. double is for physics calculations, not financial calculations.

I agree with JonathanWood. According to the values that you provided, your answer is going to produce a fractional number. Therefore, you need WStoneCost to be a double or a float. Also, you might want to use partentheses in your equations to ensure that the order of operations is carried out to your expectations.
Hope this helps!
-Gary The Bard

Dividing Math with C#

This has a potentially simple answer but I can't figure it out -
double Result = 1 / 12;
returns 0, while
double Result2 = 24 / 12;
return 2
What's going on and how can I fix it?

Try this:
double Result = 1 / (double)12;
or this:
double Result = 1 / 12D;
In C# (and also in a lot of other languages), integer division returns an integer. By casting one of the operands to double or explicitly declaring a literal double you can force the division expression to return a double and not truncate after the decimal place.

it is doing integer math because the numbers on the right are evaluated as integers.
try 1.0/12;

this will work too
Decimal.Divide(1, 12)
It has a result with higher precision, but a smaller range.

The problem is that 1 and 12 are integers (of type int, not double). This means the values ignore anything past the decimal point. When you divide 1 by 12, you get 0.083. Since anything past the decimal point is truncated for int, you are left with 0.
To get expected results, one of your operands needs to be of type double. You can do this by changing 1 to 1.0 or 12 to 12.0 (or both, as long as at least one of the operands is a double).

I think you need to cast your values
double Result = (double)1 / (double)12
has something to do with integer based math always returns an integer.....

C# and the mischief of floats

In testing as to why my program is not working as intended, I tried typing the calculations that seem to be failing into the immediate window.
Math.Floor(1.0f)
1.0 - correct
However:
200f * 0.005f
1.0
Math.Floor(200f * 0.005f)
0.0 - incorrect
Furthermore:
(float)(200f * 0.005f)
1.0
Math.Floor((float)(200f * 0.005f))
0.0 - incorrect
Probably some float loss is occuring, 0.99963 ≠ 1.00127 for example.
I wouldn't mind storing less pricise values, but in a non lossy way, for example if there were a numeric type that stored values as integers do, but to only three decimal places, if it could be made performant.
I think probably there is a better way of calculating (n * 0.005f) in regards to such errors.
edit:
TY, a solution:
Math.Floor(200m * 0.005m)
Also, as I understand it, this would work if I didn't mind changing the 1/200 into 1/256:
Math.Floor(200f * 0.00390625f)
The solution I'm using. It's the closest I can get in my program and seems to work ok:
float x = ...;
UInt16 n = 200;
decimal d = 1m / n;
... = Math.Floor((decimal)x * d)

Floats represent numbers as fractions with powers of two in the denominator. That is, you can exactly represent 1/2, or 3/4, or 19/256. Since .005 is 1/200, and 200 is not a power of two, instead what you get for 0.005f is the closest fraction that has a power of two on the bottom that can fit into a 32 bit float.
Decimals represent numbers as fractions with powers of ten in the denominator. Like floats, they introduce errors when you try to represent numbers that do not fit that pattern. 1m/333m for example, will give you the closest number to 1/333 that has a power of ten as the denominator and 29 or fewer significant digits. Since 0.005 is 5/1000, and that is a power of ten, 0.005m will give you an exact representation. The price you pay is that decimals are much larger and slower than floats.
You should always always always use decimals for financial calculations, never floats.

The problem is that 0.005f is actually 0.004999999888241291046142578125... so less than 0.005. That's the closest float value to 0.005. When you multiply that by 200, you end up with something less than 1.
If you use decimal instead - all the time, not converting from float - you should be fine in this particular scenario. So:
decimal x = 0.005m;
decimal y = 200m;
decimal z = x * y;
Console.WriteLine(z == 1m); // True
However, don't assume that this means decimal has "infinite precision". It's still a floating point type with limited precision - it's just a floating decimal point type, so 0.005 is exactly representable.

If you cannot tolerate any floating point precision issues, use decimal.
http://msdn.microsoft.com/en-us/library/364x0z75.aspx
Ultimately even decimal has precision issues (it allows for 28-29 significant digits). If you are working in it's supported range ((-7.9 x 10^28 to 7.9 x 10^28) / (100^28)), you are quite unlikely to be impacted by them.