Reputation: 137
I would like to do percentage with large number (int64 : 600 851 475 143)
My actual operation is
a = Math.round(i / 600851475143 * 100, 5);
With i also an int64 between 1 and 600851475143. The result will be between 0,00000% and 100,00000% if i'm right.
But Visual Studio Express 2013 say me that ambiguous call between methods 'System.Math.Round(decimal, int)' and 'System.Math.Round(double, int)'.
How to say to visual that the good methods is System.Math.Round(decimal, int) even if some int64 are in the operation ?
Bonus : To understand my problem, i'm trying to solve ProjectEuler.net's problem 3 : "The prime factors of 13195 are 5, 7, 13 and 29. What is the largest prime factor of the number 600851475143 ?"
I did my method and it works with 13195. But now i have to do it with 600851475143 (on x64 system), but my algo seems not to be optimezed and i would like to add an percentage progress bar to know if my EXE crash or not. My a var is this percentage...
I DON'T WANT THE ANSWER of Euleur problem 3, i just need to fix my percentage issue...
Upvotes: 1
Views: 1617
Reputation: 46919
Marking the numeric value with an M
after it will make it a decimal value. And use the correct overload for Round.
var a = Math.Round(i / 600851475143M * 100, 5);
Upvotes: 4
Reputation: 660024
If i
is an integer then the quotient is zero or one, because an integer divided by an integer is always an integer in C#. You meant to say
a = Math.round(i / 600851475143.0 * 100.0, 5);
Which forces the calculation to be in doubles, or
a = Math.round(i / 600851475143.0m * 100.0m, 5);
Which forces it to be in decimals.
The error message is correct -- it is ambiguous whether the integer result should be converted to decimal or double. It's just not pointing out the more fundamental error.
Incidentally, this error is extremely common. So common in fact that my team is working on a static analyzer to detect it. A now-deleted answer actually gave a form of the error that I see quite frequently:
a = Math.round((decimal)(i / 600851475143 * 100), 5);
That removes the ambiguity -- clearly you meant the decimal
overload -- but the calculation is done in integers, rounded to integers, and then converted to decimal! If you're going to put in a cast it has to be on one of the operands, not on the result.
Upvotes: 6