Does anyone know an algorithm to return any number to the nearest 100?
eg. I pass in 2733, algorithm returns 2700.
4599.....returns 4600
12....returns 0
98....returns 100
etc
many thanks in advance.
Does anyone know an algorithm to return any number to the nearest 100?
eg. I pass in 2733, algorithm returns 2700.
4599.....returns 4600
12....returns 0
98....returns 100
etc
many thanks in advance.
Something along the lines of
I think something would do what you want to do, now its your turn to change it in some nice looking C# code , also if you turn this into somesort of method, dont forget the case that if you want: nearest 100, and value = 550 , that it will go to the lowerboundary or the upperboundary ( adding a bool somewhere in the signature of your method )Code:int toNearest = 100; int value = 2175; int rest = value % toNearest; //check if rest is > toNearest/2 if so => int nearest = (value-rest)+toNearest else int nearest = (value-rest)
Last edited by GanglyLamb; 02-01-2006 at 09:54 AM.
Many thanks for that - my brain hurts and that really helped.
Thanks
If your brain really hurts I suggest seeing a doctor, else take a rest and get back to work when your mind is crystalclear .
Code:private static int RoundToNearest100(int iNumberToRound) { int iToNearest = 100; int iNearest = 0; bool bIsUpper = false; int iRest = iNumberToRound % iToNearest; if (iNumberToRound == 550) bIsUpper = true; if (bIsUpper == true) { iNearest = (iNumberToRound - iRest) + iToNearest; return iNearest; } else if (iRest > (iToNearest/2)) { iNearest = (iNumberToRound - iRest) + iToNearest; return iNearest; } else if (iRest < (iToNearest/2)) { iNearest =(iNumberToRound - iRest); return iNearest; } return 0; }
cant rest - have a deadline for 7th Feb!!!! ahhhh.....
Alternately, you might try:I was kind of surprised that the Math class doesn't already have a static method to round an integer.Code:static int Round(int number, int place) { if (place == 0) return number; if (number % (int)Math.Pow(10, place) >= 5 * (int)Math.Pow(10, place-1)) return (number / (int)Math.Pow(10, place) + 1) * (int)Math.Pow(10, place); return (number / (int)Math.Pow(10, place)) * (int)Math.Pow(10, place); }
If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein
I think the code he has already is a far better solution.Alternately, you might try:
Depends on how you define 'better'. One function does one specific task. The other is capable of doing many tasks. Further, the function I wrote will never return an obviously wrong answer.Originally Posted by bithub
If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein
I define better as running over 15 times as fast. I'm not exaggerating at all, I actually timed the two functions.Depends on how you define 'better'
Here is a far better implementation of your function:
This runs at the same speed as the RoundToNearest100 function the OP came up with (about 15 times as fast as your implementation).Code:static int RoundFast(int number, int place) { int i = 1; if (place <= 0) return number; while (place > 0) { i = i * 10; place--; } int r = number % i; if (r < (i / 2)) return number - r; else return number - r + i; }
I'd agree that your function is better than either one. I'm not surprised that mine was slow; using Math.Pow is just asking for a speed hit.
If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein
Well this is how I round to the nearest whole number:
Adding 0.5 turns it to 799.06. Casting this to an integer rounds it down to the nearest int, so thats 799.Code:float someNumber = 798.5600F; int closestToOneThousand = (int)(someNumber + 0.5);
If the number was say 798.46, adding 0.5 would have turned it to 798.96, and when cast to an int thats 798.
We can then take that further:
This adds 0.5*1000 (500) to the number, making it 1298.56. Then, we divide by 1000, making it 1.298.56. Casting that to an int gives us 1, which we multiply by 1000 (cancelling our devision earlier) to leave 1000, which is the correct number.Code:int roundTo = 1000; float someNumber = 798.5600F; int closestToOneThousand = (int)((someNumber + (0.5 * roundTo)) / roundTo) * roundTo;
Edit: And, I think since mine just uses casting and math, it's going to be faster than yours.
Warning: This only works where casting to an integer always returns just the whole number and ignores the decimal part. C, C++, Java and C# all behave this way I believe, but some other languages might not.
Stovellp to the rescue!
You are absolutely right, calling the method etc will probably be slower then just doing some calculations and an explicit cast.
Using an approach like that never even crossed my mind when replying to the OP.
Actually my version was still about 5-10% faster. Yours is a bit slower than you would think due to the fact that it has to use the FPU which is significantly slower than the CPU.Edit: And, I think since mine just uses casting and math, it's going to be faster than yours.
I didn't realise he only wanted to round integers. He could just use an integer with mine as well in this case (since he's multiplying by 500). Then he might not even need to do any casting. That's something to experiment withOriginally Posted by bithub