tags:

views:

195

answers:

8

I need to compute power (10, n)

Is it OK to use Math.Pow (10, n)?

Or should I use a loop?

for (int i = 0; i < n; i++){
  x*=10;
}

Which one is better? and why?

+1  A: 

Math.Pow is provided for you, and well documented.

Any gotchas are in the documentation.

Why would you not want to use a provided function?

abelenky
+4  A: 

Depends on which one communicates "10 to the power of n" more clearly.

In my case, Math.Pow(10, n) (although it could mean math, collectively, punching 10 and n in their faces as well, I dunno).

It's similar to how I'd rather algebraically express "10 to the power of n" as 10^n (or 10n) than 10 * 10 * 10 * ... * 10 n times, especially given that n is variable.

BoltClock
A: 

Yes, it is OK to use Math.Pow()

ika
+3  A: 

For integers, maybe a for loop is faster than Math.Pow which probably deals with floating-point numbers. But I seriously doubt that the difference is significant in your case (even though I do not know it).

But if you work with 32-bit signed integers, then you can only store the values of 10^n for n <= 9. But then you would gain speed (and maybe readability) by storing these nine (ten) powers of ten in an array. This is not hard: they are (1), 10, 100, 1000, ... .

If you need to compute 10^n for larger n, you do need to use floating-point numbers. And then there is no reason whatsoever not to use Math.Pow. This is as fast as it gets, and easily readable.

Andreas Rejbrand
Anyhow: a modern computer can do (tens of) millions of floating-points exponentiations per second, so unless you are doing some really tight loops in an advanced 3D game or sth, performance wouldn't be an issue...
Andreas Rejbrand
+1 for using a lookup - surely quickest if `n <= 9` (as it must be for an `int` to hold the result)
AakashM
+4  A: 

Math.Pow is better.
Here's a rule of thumb - in 99% of the scenarios, favor built-in functions over custom implementations. This makes your code clearer, saves you lots of work, and reduce chances for errors.

Only when you think of using built-in functions in ways they weren't meant to be used, or when they have severe latency problems (never encountered these scenarios myself, to be honest), should you consider building your one implementation.

Oren A
+4  A: 

If both base and exponent are integers you might consider not using Pow. But even in that case Pow is usually better because its more readable. If at least one is a floatingpoint value, use Pow.

If the exponent is 0.5 you should use Sqrt, and if the exponent is a small integer (2,3,4) expressing the formula with multiplications is faster, but less readable.

If you want to implement fast exponentiation with an integer exponent the Square-and-Multiply algorithm and not a simple loop might be what you want. But in most scenarios Pow is still faster.

CodeInChaos
A: 

if your n is big the Math.Pow doesn't work good its better to use bellow:

public static long Power(long a, long b) {
    if (b<0) {
        throw new Exception("B must be a positive integer or zero");
    }
    if (b==0) return 1;
    if (a==0) return 0;
    if (b%2==0) {
        return Power(a*a, b/2);
    } else if (b%2==1) {
        return a*Power(a*a,b/2);
    }
    return 0;
}
SaeedAlg
A: 

The answer would normally be yes, use Math.Pow().

However: if this code is really time-critical and you know you're dealing with small powers 1-9 so the result can be expressed in an Int32 then it can be worth optimizing. I just made a quick test-app and profiled the two versions (making sure the compiler hadn't optimized any code away) and the result on my laptop for the worst-case of 10^9 was that the loop was 20 times faster than Math.Pow(10,9).

But please remember, maybe this calculation is not really a bottleneck after all. If you know for a fact that it is, e.g. if you've profiled your app and found it to be a real problem, then go ahead and replace it with a loop-based method (or even better, an array-lookup). If you're merely guessing that it may a problem then I would suggest you stick to Math.Pow. In general: only optimize code that you know is a performance bottleneck.

Richard Flamsholt