pow(-1, 0.3333333333) doesn't return -1
-
how do i get around this? using pow() from math.h: -1 raised to a fraction power should return undefined (-1.#INF or whatever) when the denominator is even, yet it should return -1 when the denominator is odd e.g. -1 ^ 1/3 = -1, while -1 ^ 1/2 = undef so how can i get it to return -1 instead of undef for all fractional powers?
r -€
-
how do i get around this? using pow() from math.h: -1 raised to a fraction power should return undefined (-1.#INF or whatever) when the denominator is even, yet it should return -1 when the denominator is odd e.g. -1 ^ 1/3 = -1, while -1 ^ 1/2 = undef so how can i get it to return -1 instead of undef for all fractional powers?
r -€
Which are you asking about? How to change the behavior of
pow()with an even denominator, or the return value ofpow(-1, 0.3333333333)not being what you expect? For the former, you'll need to write your own wrapper aroundpow()since you want to change the behavior ofpow(). For the latter, 0.3333333333 is not 1/3 so I don't know howpow()will handle it. The answer to that probably lies in the depths of the floating point number representation, which I don't know enough about to give a good answer. --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Actual sign at the laundromat I go to: "No tinting or dying." -
Which are you asking about? How to change the behavior of
pow()with an even denominator, or the return value ofpow(-1, 0.3333333333)not being what you expect? For the former, you'll need to write your own wrapper aroundpow()since you want to change the behavior ofpow(). For the latter, 0.3333333333 is not 1/3 so I don't know howpow()will handle it. The answer to that probably lies in the depths of the floating point number representation, which I don't know enough about to give a good answer. --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Actual sign at the laundromat I go to: "No tinting or dying."thanks... my problem is that im making a calculator program and when someone types "(-1)^(1/3)" it returns undefined... which is wrong, the answer is 1 i guess i can't get around that issue unless i represent fractions as numerator/denominator instead of the actual ratio value oh well thanks for the help though
r -€
-
thanks... my problem is that im making a calculator program and when someone types "(-1)^(1/3)" it returns undefined... which is wrong, the answer is 1 i guess i can't get around that issue unless i represent fractions as numerator/denominator instead of the actual ratio value oh well thanks for the help though
r -€
-
Um, no. (-1)^(1/3) = 0.5+0.866i (as one of many roots. -1 is another root). "pow" only supports real numbers, not imaginary. FYI: 1^3 != -1, thus your answer is obviously in error. Tim Smith I'm going to patent thought. I have yet to see any prior art.
well, the cube root of -1 is -1 (right?) and a number to a fraction power (a/b) is the b'th root of the funtion to the a'th power... am i not correct?
r -€
-
well, the cube root of -1 is -1 (right?) and a number to a fraction power (a/b) is the b'th root of the funtion to the a'th power... am i not correct?
r -€
Is "the" cube root of -1, -1? No. It is one of at least two cube roots. That is part of problem. Probably the real problem is that you can probably only compute a root when 1/x and x is an integer. As someone already pointed out, due to floating point limitations, it is next to impossible to get 1/x and have x an integer. Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
Um, no. (-1)^(1/3) = 0.5+0.866i (as one of many roots. -1 is another root). "pow" only supports real numbers, not imaginary. FYI: 1^3 != -1, thus your answer is obviously in error. Tim Smith I'm going to patent thought. I have yet to see any prior art.
Hi there Tim is absolutely right. The easiest way to calculate a power is using logarithms, so let say we have this r = x ^ y so to calculate r will be something like this r = e ^ (y * log x) where e^ and log can be obtained using the Taylor Polynomial f(x) = f(a) + f'(a) * (x-a)/1! + f"(a) * (x-a)^2/2! + ...+ fN(a) * (x-a)^n/n! where f', f" ... fN are the first n derivatives of f, and a is a value with which all the funcion can be calculated, for e^ can be 0 for ln, 1. Anyway, like I was saing the use of logarithm is the reason you are not geting the real root you are looking for, as you can see in your case you would have something like this r = e ^ ( 1/3 * log -1) and as we all know log -1 has no solution on the domain of real numbers, the solution is an imaginary number, -PI i, and there is your problem. So you have some options here, one is to do some analitical preprocessing before the actual calculations, the other one is to redefine pow and/or log to handle complex numbers. Fabian
-
Is "the" cube root of -1, -1? No. It is one of at least two cube roots. That is part of problem. Probably the real problem is that you can probably only compute a root when 1/x and x is an integer. As someone already pointed out, due to floating point limitations, it is next to impossible to get 1/x and have x an integer. Tim Smith I'm going to patent thought. I have yet to see any prior art.
>Is "the" cube root of -1, -1? >No. >It is one of at least two cube roots. By that logic, pow(1, 1/3) should return undefined too, since -1/2 + j * sqrt(3)/2 and -1/2 - j * sqrt(3)/2 are also solutions. (It doesn't. It returns 1, as you would expect.) For what it's worth, the calculator in Windows XP returns "Invalid input for function" when you try to do (-1)^(1/3). I think that's what most calculators that don't handle complex numbers do.
-
how do i get around this? using pow() from math.h: -1 raised to a fraction power should return undefined (-1.#INF or whatever) when the denominator is even, yet it should return -1 when the denominator is odd e.g. -1 ^ 1/3 = -1, while -1 ^ 1/2 = undef so how can i get it to return -1 instead of undef for all fractional powers?
r -€
I think it is because of this reason: a^x = y ln(a^x) = ln(y) x.ln(a) = ln(y) e^(x.ln(a)) = y ln(a) is undefined for a <= 0 it should work for a,x,y are of type complex. I have done such a thing many years ago. It works also for -1 ^ 1/2 (which is the complex number "i" or "j") written as y.re=0 and y.im=1 . I am not sure if pow can be called as "complex y = pow( complex a, complex x )", if not, you need to overload it in some way. That's a challenge!! :) Wish it helps some. Michel
-
I think it is because of this reason: a^x = y ln(a^x) = ln(y) x.ln(a) = ln(y) e^(x.ln(a)) = y ln(a) is undefined for a <= 0 it should work for a,x,y are of type complex. I have done such a thing many years ago. It works also for -1 ^ 1/2 (which is the complex number "i" or "j") written as y.re=0 and y.im=1 . I am not sure if pow can be called as "complex y = pow( complex a, complex x )", if not, you need to overload it in some way. That's a challenge!! :) Wish it helps some. Michel
thanks, i get what you're saying i think maybe i will implement sets and complex numbers into my calculator program to get around this.. i've never heard of the "complex" class, though.. is it STL? so far i'm only using STL classes and would like to keep it to a bare minimum of external libraries
r -€
-
>Is "the" cube root of -1, -1? >No. >It is one of at least two cube roots. By that logic, pow(1, 1/3) should return undefined too, since -1/2 + j * sqrt(3)/2 and -1/2 - j * sqrt(3)/2 are also solutions. (It doesn't. It returns 1, as you would expect.) For what it's worth, the calculator in Windows XP returns "Invalid input for function" when you try to do (-1)^(1/3). I think that's what most calculators that don't handle complex numbers do.
-
Read the second half of the message please. I amended my response long before you posted your message where I talk about the problem of detecting the 1/x where x is an integer. Tim Smith I'm going to patent thought. I have yet to see any prior art.
Sorry. I didn't mean to offend you. I guess I should have worded that more carefully. I was just trying to point out that his question was a little deeper than people were giving it credit for. As you said, the floating point representation of 1/3 is not exact. Yet, pow(1,1/3) correctly returns 1, even though there are two equally valid complex solutions. Why, then, shouldn't pow(-1,1/3) return -1? It is, after all, the only real-valued solution. I guess the ANSI C developers opted for efficiency rather than completeness. Again, sorry if I offended you. That wasn't my intention.
-
thanks, i get what you're saying i think maybe i will implement sets and complex numbers into my calculator program to get around this.. i've never heard of the "complex" class, though.. is it STL? so far i'm only using STL classes and would like to keep it to a bare minimum of external libraries
r -€
Hi, Yes Complex is a class of STL, but it won't help you either, try this
complex<double> x, y, r;
x.real(-1.0);
x.imag(0.0);y.real(1.0/3.0);
y.imag(0.0);r = pow(x, y);
//r.real is -1.#IND00000
//r.imag is 0.0
//Still the same answerr = exp(y * log(x));
//r.real is 0.5
//r.imag is 0.866025
//This is the answer Tim already gave you.So as I said, you will have to do some preprocessing or redefine pow yourself Fabian
-
Hi, Yes Complex is a class of STL, but it won't help you either, try this
complex<double> x, y, r;
x.real(-1.0);
x.imag(0.0);y.real(1.0/3.0);
y.imag(0.0);r = pow(x, y);
//r.real is -1.#IND00000
//r.imag is 0.0
//Still the same answerr = exp(y * log(x));
//r.real is 0.5
//r.imag is 0.866025
//This is the answer Tim already gave you.So as I said, you will have to do some preprocessing or redefine pow yourself Fabian
thanks for the info... ill leave the fix for a later date
r -€