Whenever you do math between two number types you should expect your answer will be in precision of the lowest precision operand. You should either declare the 100 as a constant of the appropriate type or use Numeric type suffixes[^].
Just adding a .0 isn't good practice. Do you know for sure what type it becomes by adding a .0? It could be a decimal, or a float, or a double. Even if you know what type the compiler chooses by default, will other people who have to read or update your code? See my previous post in the thread for how to make sure the number you are dealing with is cast as exactly the type you need.
Sorry there is a mathematical mistake what I needed to know is when dividing an integer with a remainder I was getting
double variable(2425) / 100 would give you 24.0 , I was wondering why I wasn't getting 24.25
solution was because I was dividing an integer into another integer,
I corrected this simply by multiplying 100.00 instead of 100
dbRecipeTotal = (double)(((double)(RI.Quantity / dbRecipeTotalQuantity)) * ((double)(InvItem.Price / 100)));
this will make sure that you are always in the precision your looking for, indepentant of whether you use a lower precision numeral type.
ely_bob, your solution still doesn't work because (InvItem.Price / 100) will be 24, so ((double)(InvItem.Price / 100)) will be 24.0
It needs to be ((double)InvItem.Price / 100). I didn't cast the 100 to double because when one of the arguments to operator/ is a double, the other one is automatically cast (I think).
You are always going to store 24.25 in a floating point number exactly. 24.25 is a power of two. You should never see any of the results you listed (except 24.25) no matter what print formatting is specified.
[Stepping on my soapbox]
When dealing with floating point numbers, you should never assume that a number will be stored exactly. While some numbers can be stored exactly, most will not be.
From the cases I have encountered, too many people assume that a floating point number is good enough for exact numerical needs. But if the value 24.24999999999999 instead of 24.25 would be considered incorrect in your application, you should not be using floating point values.
Time and time again I have been called in to analyze why dollar values were coming in off by a penny or two (or more), and it has always* boiled down to the choice of using floating point representation to store exact values.
* Since 1992 I have encountered only 2 instances where the problem was an actual bug in the library.
The answer lies in the way implicit data type conversion works. Dividing and integer by and integer will never yeild a float or a double. So, InvItem.Price / 100 becomes 24 and not 24.25. I'm sure you understand the rest. To get correct answer do something like
I think InvItem.Price is int so 2425/100=24
you can write : InvItem.Price/100.0 to get correct result:
(this is tested and returns correct result):
double Quantity = 28.88887;
double dbRecipeTotalQuantity = 28.88887;
int Price = 2425;
double dbRecipeTotal = (Quantity / dbRecipeTotalQuantity) * (Price / 100.0);
And what did telerik tell you when you asked them?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
Your Linq query is asking for the wrong thing from the XDocument.
The Descendents() method returns descendents of the object (in this case, the XDocument) which have the specified name (in this case 'countries'). So it is yielding a single enumerable element (because your XML Document has only one <countries> element).
What you really need is to get the 'country' descendents of the XDocument: from xmlDoc.Descendents("country") and then just get the Value property of the elements of the enumeration. Here's some code that works for you:
var countries = from country in xmlDoc.Descendants("country")
Name = country.Value
Last Visit: 31-Dec-99 19:00 Last Update: 6-Dec-22 10:23