Thread: return value to nearest 100?

He could just use an integer with mine as well in this case (since he's multiplying by 500)

It would increase the speed a little, but it would still use the FPU because the result of your division returns a floating point variable. Even thought you wouldn't be using any explicit casts, C# still has to do some implicit casts behind the scenes.

That's true. However, I think mine will stay at about the same speed no matter what you're rounding to. Yours might be faster rounding to the nearest 100, but is it faster when rounding to the nearest 1,000 or 10,000?

Well since I have some free time, I decided to do a bit of testing to see

Here are the two functions:

Code:

    static int Round1(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;
    }

    static int Round2(int someNumber, int place)
    {
        int roundTo = 1;
        if (place <= 0)
            return (int)someNumber;
        while (place > 0)
        {
            roundTo = roundTo * 10;
            place--;
        }
        return ((someNumber + (roundTo / 2)) / roundTo) * roundTo;
    }

I'm running the functions in a control loop 1,000,000,000 times.
When rounding to the nearest 100, both functions took exactly 40s. When rounding to the nearest 10,000, yours took 40s, and mine took 41.5s. I guess we can conclude that your function is faster when rounding to larger numbers

I'd be interested to see how much of that time is spent in this part:

Code:

		while (place > 0)
		{
			roundTo = roundTo * 10;
			place--;
		}

Also, I'm pretty sure this line can be safely removed:

Code:

		if (place <= 0)
			return (int)someNumber;

The place can't be < 0 (it's an integer) and if it's 0, I believe it works out the correct number.

I'd be interested to see how much of that time is spent in this part:

I'm guessing about 10-40% depending on what you are rounding to. I can't really think of a faster way of doing it though.

The place can't be < 0 (it's an integer) and if it's 0, I believe it works out the correct number.

Integers can be less than 0...

Originally Posted by bithub

Integers can be less than 0...

What the hell am I thinking.