None. As you can read in the ES7 spec, both Math.pow and the ** exponentation operator cast their arguments/operands to numbers and use the very same algorithm to determine the result.
Addendum: this changed with the introduction of the BigInt type in ES2020, whose values are only supported by operators (including **) but not the Math object.
Videos
None. As you can read in the ES7 spec, both Math.pow and the ** exponentation operator cast their arguments/operands to numbers and use the very same algorithm to determine the result.
Addendum: this changed with the introduction of the BigInt type in ES2020, whose values are only supported by operators (including **) but not the Math object.
Late to the party -- I just wanted to add that as much as there is no difference between the two ways, I recently came to realize that the ** exponentiation operator isn't supported in Internet Explorer, so developers that are interested in extensive cross-browser support for their applications, may prefer to choose the Math.pow(...) over the exponentiation operator.
Brief :
use parseInt or Math.floor to have y/2 as integer, unleness you will not reach 0 which is the stopper of recursion .
Details
if you want to transalte [C Algo]:
int power(int x, unsigned int y)
{
if( y == 0)
return 1;
else if (y%2 == 0)
return power(x, y/2)*power(x, y/2);
else
return x*power(x, y/2)*power(x, y/2);
}
To [JS Algo] , you will have :
function power(x,y){
if(y===0){return 1}
else if (y%2 ===0){
return power(x,parseInt(y/2))*power(x,parseInt(y/2))
}else{
return x*power(x,parseInt(y/2))*power(x,parseInt(y/2))
}
}
DEMO :
function power(x,y){
if(y===0){return 1}
else if (y%2 ===0){
return power(x,parseInt(y/2))*power(x,parseInt(y/2))
}else{
return x*power(x,parseInt(y/2))*power(x,parseInt(y/2))
}
}
console.log(power(3,2))Try this out
It will give you the same result of JavaScript build in method ( Math.pi(x, y)) but the only problem is you can't use Power as decimal number.
Math.my_pow = (x, y) => {
if (typeof x != "number" || typeof y != "number")
throw "(x) and (y) should only be number";
if (y == 0) return 1;
if (x == 0 && y > 0 ) return 0;
const base = x;
var value = base;
var pow = y;
if (y < 0) pow = y * -1;
for (var i = 1; i < pow; i++) {
value *= base;
}
if (y < 0) return 1 / value;
return value;
};
try {
console.log( Math.my_pow(0, -3) );
console.log( Math.pow(0, -2) );
console.log( Math.my_pow(-5, -3) );
console.log( Math.pow(-5, -3) );
console.log( Math.my_pow(8, -7) );
console.log( Math.pow(8, -7)) ;
} catch (err) {
console.log(err);
}at the cost of some precision
How much loss of precision? If you only need correct answers by a factor of 2, you could use bitwise manipulation.
function pow2(n) {
return 2 << (n-1);
}
console.log(pow2(n) === Math.pow(2, n));
The Number constructor (including number literals) use only floating point numbers. This function converts the floats to 32-bit integers as described here.
Otherwise, I doubt you'll be able to beat the optimized native implementation of Math.pow.
jsPerf is a great tool for trying multiple techniques to find the fastest one.
This could vary quite a bit by browser or operating system, but so far it turns out that Math.pow is much faster in my environment (Chrome 42, 64-bit Linux) until you open up dev tools. With dev tools open, it's slightly faster to multiply the number as many times as you need depending on the power, as in the following example:
function pow(num, pow) {
var result = num;
while (--pow) {
result *= num;
}
return result;
}
I'm running out of different ideas, but you can see what I have so far here:
http://jsperf.com/math-pow-alternatives
There is also a lot of overhead just to calling a function (hundreds of thousands of times). In this case it seems like Math.pow is the way to go, but there might be other ways to improve performance (or at least perceptible performance). If the code is blocking and the browser is experiencing some lag, you might try using web workers, or limiting the number of calculations per frame. You could also try to reduce the amount of function calls, or make sure you're interacting very minimally with the DOM (especially during the calculations, but preferably not at all).
Without a more concise code sample it will be difficult to fine-tune your code's performance.