I am writing a logging system for our site and it looks at changes to Entities to see if they should be logged. I keep having a problem where the version of the Entity in the database shows decimal numbers (in string format) as "132.0000" and the current Entity has it as "132" with no decimal places.
Is there a way that I can force it to either remove the ".0000" from one or add it to the other?
Hm, simply parse the value from the database into a decimal and compare it to the decimal you already have?
You can try:
if(132 == Convert.ToDecimal("132.0000")
{
//Do Stuff
}
Replace 132 and "132.0000" with your appropriate values.
Also, if you wanted to remove the decimal portion of "132.0000", you can do:
string dec = "132.0000";
dec = dec.Substring(0,dec.IndexOf("."));
Convert the entry back to decimal, I'd say.
If you always want to remove the decimal, why not cast the object to an int and then make a string of it?
Provided all of the comparisons are numerics, you have to find the commonality between the two. In your post, you have already provided the answer. You need an integral number rather than a floating point number. Cast both strings to one of the integral types and compare.
You can use formatter string : F4
xxx.ToString("F4")
Related
I am getting data into a text field and I need to display it as a percentage. Is there a function to perform this?
Ex: in my column I have "0.5", "0.1","0.2","0.25" etc., which needs to be displayed as
50%,10%,20%,25% etc., What is the best way to do it?
You should do this in two phases:
Parse the text as a number so you've got the value as your "real" type. (As a general rule, parse from text as early as you can, and format to a string as late as you can... operations between the two will be a lot simpler using the natural type.)
Format the number as a percentage using the standard numeric format string for percentage
So:
decimal percentage = decimal.Parse(input);
string output = percentage.ToString("p0");
Notes:
You should consider both input and output culture; are you always expecting to use "." as the decimal separator, for example?
Use decimal rather than double to exactly represent the value in the text (for example, the text could have "0.1" but double can't hold a value of exactly 0.1)
You can add things like desired precision to the formatting; see the linked docs for details; the example gives just an integer percentage, for example
Easiest would be to parse it (must be a double) then convert it back to a string, formatting it as a percentage.
var percentageString = double.Parse(doubleString).ToString("p1");
Now, some of you hoity-toity types may say that decimal is the correct type to use in this case.
Well, yes, if you need an additional 12-13 digits of precision.
However, most of us real folk (and I'm all about keeping it real) are fine with double's 15-16 digits of precision.
The real choice is whether or not your code is using doubles or decimals in the first place. If you are using doubles in your code, just stick with doubles. If decimals, stick to decimals. What you definitely do want to avoid is having to convert between the two any more than is absolutely necessary, as there be dragons. And unexpected runtime bugs that can corrupt your data. But mostly dragons.
This is so many times repeated at SO, but I would want to state my question explicitly.
How is a decimal which would look like 2.0100 "rightly" presented to the user as
another "decimal" 2.01?
I see a lot of questions on SO where the input is a string "2.0100" and need a decimal 2.01 out of it and questions where they need decimal 2.0100 to be represented as string "2.01". All this can be achieved by basic string.Trim, decimal.Parse etc. And these are some of the approaches followed:
decimal.Parse(2.0100.ToString("G29"))
Using # literal
Many string.Format options.
Various Regex options
My own one I used till now:
if (2.0100 == 0)
return 0;
decimal p = decimal.Parse(2.0100.ToString().TrimEnd('0'));
return p == 2.0100 ? p : 2.0100;
But I believe there has to be some correct way of doing it in .Net (at least 4) which deals with numeric operation and not string operation. I am asking for something that is not dealing with the decimal as string because I feel that ain't the right method to do this. I'm trying to learn something new. And would fancy my chances of seeing at least .1 seconds of performance gain since I'm pulling tens of thousands of decimal values from database :)
Question 2: If it aint present in .Net, which is the most efficient string method to get a presentable value for the decimal?
Edit: I do not just want a decimal to be presented it to users. In that case I can use it as a string. I do want it as decimal back. I will have to process on those decimal values later. So going by ToString approach, I first needs to convert it to string, and then again parse it to decimal. I am looking for something that doesn't deal with String class. Some option to convert decimal .20100 to decimal .201?
The "extra zeroes" that occur in a decimal value are there because the System.Decimal type stores those zeroes explicitly. For a System.Decimal, 1.23400 is a different value from 1.234, even though numerically they are equal:
The scaling factor also preserves any trailing zeroes in a Decimal number. Trailing zeroes do not affect the value of a Decimal number in arithmetic or comparison operations. However, trailing zeroes can be revealed by the ToString method if an appropriate format string is applied.
It's important to have the zeroes because many Decimal computations involve significant digits, which are a necessity of many scientific and high-precision calculations.
In your case, you don't care about them, but the appropriate answer is not "change Decimal for my particular application so that it doesn't store those zeroes". Instead, it's "present this value in a way that's meaningful to my users". And that's what decimal.ToString() is for.
The easiest way to format a decimal in a given format for the user is to use decimal.ToString()'s formatting options.
As for representing the value, 2.01 is equal to 2.0100. As long as you're within decimal's precision, it shouldn't matter how the value is stored in the system. You should only be worried with properly formatting the value for the user.
Numbers are numbers and strings are strings. The concept of "two-ness" represented as a string in the English language is 2. The concept of "two-ness" represented as a number is not really possibly to show because when you observe a number you see it as a string. But for the sake of argument it could be 2 or 2.0 or 02 or 02.0 or even 10/5. These are all representations of "two-ness".
Your database isn't actually returning 2.0100, something that you are inspecting that value with is converting it to a string and representing it that way for you. Whether a number has zeros at the end of it is merely a preference of string formatting, always.
Also, never call Decimal.parse() on a decimal, it doesn't make sense. If you want to convert a decimal literal to a string just call (2.0100).ToString().TrimEnd('0')
As noted, a decimal that internally stores 2.0100 could differ from one that stores 2.01, and the default behaviour of ToString() can be affected.
I recommend that you never make use of this.
Firstly, decimal.Parse("2.0100") == decimal.Parse("2.01") returns true. While their internal representations are different this is IMO unfortunate. When I'm using decimal with a value of 2.01 I want to be thinking:
2.01
Not:
struct decimal
{
private int flags;
private int hi;
private int lo;
private int mid;
/methods that make this actually useful/
}
While different means of storing 2.01 in the above structure might exist, 2.01 remains 2.01.
If you care about it being presented as 2.01 and not as 2.0 or 2.0100 then you care about a string representation. Your concern is about how a decimal is represented as a string, and that is how you should think about it at that stage. Consider the rule in question (minimum and maximum significant figures shown, and whether to include or exclude trailing zeros) and then code a ToString call appropriate.
And do this close to where the string is used.
When you care about 2.01, then deal with it as a decimal, and consider any code where the difference between 2.01 and 2.0100 matters to be a bug, and fix it.
Have a clear split in your code between where you are using strings, and where you are using decimals.
Ok, so I'm answering for myself, I got a solution.
return d / 1.00000000000000000000000000000m
That just does it. I did some benchmarking as well (time presented as comments are mode, not mean):
Method:
internal static double Calculate(Action act)
{
Stopwatch sw = new Stopwatch();
sw.Start();
act();
sw.Stop();
return sw.Elapsed.TotalSeconds;
}
Candidates:
return decimal.Parse(string.Format("{0:0.#############################}", d));
//0.02ms
return decimal.Parse(d.ToString("0.#############################"));
//0.014ms
if (d == 0)
return 0;
decimal p = decimal.Parse(d.ToString().TrimEnd('0').TrimEnd('.'));
return p == d ? p : d;
//0.016ms
return decimal.Parse(d.ToString("G29"));
//0.012ms
return d / 1.00000000000000000000000000000m;
//0.007ms
Needless to cover regex options. I dont mean to say performance makes a lot of difference. I'm just pulling 5k to 20k rows at a time. But still it's nice to know a simpler and cleaner alternative to string approach exists.
If you liked the answer, pls redirect your votes to here or here or here.
Console.WriteLine("Enter a double number");
string numberInput = Console.ReadLine();
double number = Double.Parse(numberInput)
My question is what is the last line of code doing? Is it doing the same thing as ToDouble?
The very short answer is:
Converts a string value into a double. e.g.
"2.3"(String) will become 2.3(double).
You have many choices on how to do this:
Double.TryParse()
Convert.ToDouble()
Double.TryParse() is handy if you don't know 100% that the input string is going to be a number value.
It is converts a string to double, the Console.ReadLine() methods read a string data and store it on string variable named numberInput, to convert from that string to double, Double.Parse is called we passing to it the numberInput string and it will convert it to double.
"Converts the string representation of a number in a specified style to its double-precision floating-point number equivalent."
See MSDN.
It's taking String input and interpreting it as numeric input - Double in this case. String and Double are quite different types. For one, mathematical operations can be performed on Double.
Converts the string representation of a number to its double-precision floating-point number equivalent.
MSDN: http://msdn.microsoft.com/en-us/library/system.double.parse.aspx
It's calling the Double.Parse method. According to the MSDN page it
Converts the string representation of a number to its double-precision floating-point number equivalent.
As per #DoctorMick's answer: It does the same thing as the Convert.ToDouble method.
In this case it's used because the code is getting a string from the user which can be thought of as a sequence of letters. We would want to get this into the proper type that we want to work with, which in this case is Double. Double has the parse method for this.
The data read into the variable numberInput is a string. The last line parses this into the type System.Double, so that it is better typed for other operations.
There is no guarantee that numberInput contains a valid numeric value, in which case the Parse method will throw an exception that you can catch.
There have been 7 different answers yet everyone seems to have overlooked the question of is it doing the same as ToDouble. The short answer is yet, it is doing the same, in fact ToDouble calls double.Parse internally.
When using double.Parse, it seems to like to string away any trailing (insignificant) zeros from the string that I'm converting. I would like double.Parse to keep to places after the decimal. For example, here is some code:
tobereturned.MouseSensitivty = double.Parse(String.Format("{0:#.##}", tempstring[1]));
Debug.WriteLine("Converted " + String.Format("{0:#.##}", tempstring[1]) + " to " + tobereturned.MouseSensitivty);
The Debugger then writes
Converted 4.00 to 4
So it seems like double.Parse is doing something fishy here.
P.S. MouseSensitivity is also of the type double, so I can't do any string operations on it.
Your question is meaningless. Doubles don't have "places after the decimal" in the first place. They don't store anything that looks remotely like a "decimal representation of a number" internally. In fact, they don't store anything internally that even looks like recognizable text.
It reports 4 because 4.00 is exactly equal to 4. It is displaying the number "exactly four with no fractional part" as text according to its default rules for converting numbers to text.
Please read this. Yes, it is long, and difficult, but it is simply not possible to use floating-point numeric types properly without a real understanding of this material - and it doesn't matter what language you're using, either.
The double data type is simply a number; it doesn't keep track of the string that was parsed to create the value. Its string representation only comes into play when .ToString() is called.
If you know you always want two places after the decimal you can right-fill with zeros.
it is not the job of the double type to keep track of your desired display format.
Double does not store redundant zeros. In your view or presentation layer, you might want to format it to show you want it to appear, e.g., String.Format("{0:#.##}", doubleVariable)
I am using Convert.ChangeType() to convert from Object (which I get from DataBase) to a generic type T. The code looks like this:
T element = (T)Convert.ChangeType(obj, typeof(T));
return element;
and this works great most of the time, however I have discovered that if I try to cast something as simple as return of the following sql query
select 3.2
the above code (T being double) wont return 3.2, but 3.2000000000000002. I can't realise why this is happening, or how to fix it. Please help!
What you're seeing is an artifact of the way floating-point numbers are represented in memory. There's quite a bit of information available on exactly why this is, but this paper is a good one. This phenomenon is why you can end up with seemingly anomalous behavior. A double or single should never be displayed to the user unformatted, and you should avoid equality comparisons like the plague.
If you need numbers that are accurate to a greater level of precision (ie, representing currency values), then use decimal.
This probably is because of floating point arithmetic. You probably should use decimal instead of double.
It is not a problem of Convert. Internally double type represent as infinite fraction of 2 of real number, that is why you got such result. Depending of your purpose use:
Either Decimal
Or use precise formating {0:F2}
Use Math.Flor/Math.Ceil