Recommendations: 2
Earlier this evening I received an SOS from my sister, who is homeschooling her two very bright young daughters. The elder daughter was solving problems in her algebra book, and came across this one:
Find [(4)^2]^3/4 .
Young Emily multiplied two times 3/4, and got 3/2. She raised 4 to the power three, getting 64. She then took its square root, getting 8i.
Much to her consternation, the book had a different answer. They squared 4, getting 16, and eventually found 8 as the answer.
Which answer is wrong? Or is neither wrong? Why?
In any case, what rule should students learn to help them avoid this problem?
I have already written her an answer, but I wonder what the good folks on this board will make of it.
Loren

Recommendations: 0
Loren
This is an interesting question on order of operations and properties of exponents with an associativity wrinkle thrown in. I am teaching a Math for Elementary Education majors class this semester and I will bring it to them to discuss. Thanks.

Recommendations: 3
From a programming POV: [(4)^2]^3/4 =[16]^3/4 =4096/4 =1024
^ has a higher precedence than /

Recommendations: 0
^ has a higher precedence than /
Well, sure. What I wrote was a serialization of the actual printed formula, and I should have been more sensitive to disambiguation. Written properly, the serialized formula is:
[(4)^2]^(3/4)
Looking at it from a programming POV, a standard compiler will evaluate the expression from the inside out, yielding the "real" answer (8). However, a good optimizing compiler will recognize that the two costly exponentiation operators can be combined into one. Such a compiler would presumably (I haven't tested this) produce the "imaginary" answer (8i), or it might choke on taking a fractional power of a negative number.
I know of no compiler that would recognize that the expression can be evaluated to two different answers.
LC

Recommendations: 0
I know of no compiler that would recognize that the expression can be evaluated to two different answers.
Being a compiler, it would probably recognize it as a constant and evaluate/reduce it. (FWIW, there are some compiler tools that look for ambiguous expressions and generate warnings for them. I've not seen one reject this specific case, but it doesn't stretch credulity that some might. I have seen complaints  at compile time  about negative numbers being exponentiated.)
I could also imagine a compiler complaining about it, and refusing to answer: exponentiation is often done by means of logarithms, and could be evaluated:
e(ln(e(ln(4)*2))*0.75)
and ln(4) would yield a domain error. Most, however, are smart enough to recognize squaring as a special case. I don't know if any would also realize that it could be recast legitimately as:
(4)^(6/4) = r = 4 r = r * r; r = r * r * r; r = sqrt(sqrt(tmp)) = 8
In an expression, it's likely that some machines would evaluate this or similar reduction considerably faster than most others.
rj

Recommendations: 0
ln(4) would yield a domain error
Not in Gnu Fortran, I believe. The Fortran call log(x), where x is complex, generates a complex answer (the principal value of the complex logarithm). These doc files
http://gcc.gnu.org/onlinedocs/gfortran/LOG.html
say as much, though they do not specify what would happen if the log function is called on a negative constant.
We are actually getting very close to the heart of the matter, and to the correct answer to the question in the OP. If anyone has not yet figured it out, this post contains enough information to do so.
Loren

Recommendations: 0
LorenCobb: Not in Gnu Fortran, I believe. The Fortran call log(x), where x is complex, generates a complex answer (the principal value of the complex logarithm). These doc files
http://gcc.gnu.org/onlinedocs/gfortran/LOG.html
say as much, though they do not specify what would happen if the log function is called on a negative constant.
That is what I'd expect, FORTRAN having had COMPLEX data types since day IV (if not earlier). However, the argument is a REAL (or integer?), and I've long since forgotten FORTRAN's type conversion and promotion rules (and I don't know what they say about evaluation of constants at compile time). Unlike C, they're probably quite strict (ISTR that parentheses are inviolate in FORTRAN).
If you're angling to do all this in complex arithmetic, then the result probably comes out very weird if you apply Euler's identity, e^(i(theta)) = cos(theta) = i*sin(theta) after doing the original exponent rearrangement. If you do, then you get the ln(4) ~= 1.386... + pi*i. Multiply by 3/2 (2.07944... + 4.7123...i) and exponentiate, and the result is 8i.
But I think most of us would understand any of these answers (domain error, 8, 8i).
rj

Recommendations: 0
I don't see this as a math problem, but rather an order of precedence problem.
So "the answer" is to know the correct order of precedence as the notation demands.
One can "optimizer" under the order of precedence rules using heuristics which maintain coherence of the equation, but that doesn't change the fundamental problem from being one of symantecs.

Recommendations: 0
yttire: I don't see this as a math problem, but rather an order of precedence problem. So "the answer" is to know the correct order of precedence as the notation demands.
Well, no. It is not a precedence problem, because with real numbers the following identity should hold:
(x^a)^b) = x^(ab) = x^(ba) = (x^b)^a
However, if x < 0 then some of the steps may yield complex numbers, and then powers and roots (and logarithms, etc) are operations that can have multiple answers. None of those answers are wrong, so it is not a precedence issue. In fact, if you were to define a "required" precedence, then you would be eliminating valid answers.
Euler ran into this problem, and apparently (according to Wikipedia) wrestled with it for years. His ultimate solution was to advise that beginning students of algebra learn complex numbers in polar form from the outset, and he wrote a textbook that did just that.
http://en.wikipedia.org/wiki/Complex_number#History
A simple but drastic alternative is to teach that elementary algebra cannot properly solve problems in which a root is taken of a negative number. IIRC, that was the way I was first taught. Now, many decades later, I suspect that that approach might have been a mistake.
It's a difficult pedagogical decision, because some students in the "normal" range of intelligence are just not intellectually equipped to handle anything beyond the simplest forms of algebra. Complex numbers in polar form may be a step too far for them.
Loren

Recommendations: 1
Loren,
Earlier this evening I received an SOS from my sister, who is homeschooling her two very bright young daughters. The elder daughter was solving problems in her algebra book, and came across this one:
Find [(4)^2]^3/4 .
Young Emily multiplied two times 3/4, and got 3/2. She raised 4 to the power three, getting 64. She then took its square root, getting 8i.
Much to her consternation, the book had a different answer. They squared 4, getting 16, and eventually found 8 as the answer.
Which answer is wrong? Or is neither wrong? Why?
the parentheses/brackets force the operations to be performed in a particular sequence. Thus,
[(4)^2]^3/4 = [16]^3/4 = 8
is the only correct solution. The text is correct.
Norm.

Recommendations: 0
Loren,
Looking at it from a programming POV, a standard compiler will evaluate the expression from the inside out, yielding the "real" answer (8). However, a good optimizing compiler will recognize that the two costly exponentiation operators can be combined into one. Such a compiler would presumably (I haven't tested this) produce the "imaginary" answer (8i), or it might choke on taking a fractional power of a negative number.
The standards of most programming languages, including Fortran and C/C++, explicitly forbid optimizations that fail to preserve the integrity of parentheses in order to give programmers control of the sequence of operations when it matters. Thus, such an optimization is illegal.
Norm.

Recommendations: 0
rmhj,
I could also imagine a compiler complaining about it, and refusing to answer: exponentiation is often done by means of logarithms, and could be evaluated:
e(ln(e(ln(4)*2))*0.75)
and ln(4) would yield a domain error. Most, however, are smart enough to recognize squaring as a special case. I don't know if any would also realize that it could be recast legitimately as:
(4)^(6/4) = r = 4 r = r * r; r = r * r * r; r = sqrt(sqrt(tmp)) = 8
In an expression, it's likely that some machines would evaluate this or similar reduction considerably faster than most others.
Most compilers do distinguish between the case in which the exponent is of an INTEGER (C int, long, or char, either signed or unsigned) type and the case in which the exponent is of a REAL (C float, double, or long double) type. Note that (x)^n is mathematically legal if n is an integer.
Algorithmically, the logarithmic approach that you describe (a^b > exp(log(a)*b) applies only if b is of a REAL type. If the exponent is an integer, the following function is more efficient. Note that this algorithm handles negative arguments correctly.
C/C++ Version
float expon(float x, int n) { float y, z; int k;
if (n < 0.0) y = 1.0 / x; else y = x;
k = abs(n); whioe (k > 0) { if (k % 2 > 0) z *= y;
y *= y; k /= 2; }
return z; }
Fortran Version
real function expon(x,n) implicit none real x, y, z integer n, k
if (n.lt.0) then y=1.0/x else y=x end if
z=1.0
k=iabs(n) do while (k.gt.0) if (mod(k,2).ne.0) z = z*y
y=y*y k=k/2 end do
expon=z
return end
Norm.

Recommendations: 2
Lauren,
Well, no. It is not a precedence problem, because with real numbers the following identity should hold:
(x^a)^b) = x^(ab) = x^(ba) = (x^b)^a
However, if x < 0 then some of the steps may yield complex numbers, and then powers and roots (and logarithms, etc) are operations that can have multiple answers. None of those answers are wrong, so it is not a precedence issue. In fact, if you were to define a "required" precedence, then you would be eliminating valid answers.
I hate to break this to you, but it absolutely is a problem of precedence. Your supposed identity is valid only if x is a positive real value or zero  and you actually provided a counterexample that shows how it fails when x is negative.
Note that considering all four fourth roots implied by the exponent of 3/4, which differ by multiples of 90 deg. in phase angle, also does not solve this problem. If one evaluates all four roots of the original expression, one gets 8, 8i, 8, and 8i. Exchanging the exponents, the four roots of (4)^(3/4) have phase angles of 45, 135, 135, and 45 degrees. When squared, these values yield only 8i and 8i  one does not get the real values.
Norm.

Recommendations: 0
the parentheses/brackets force the operations to be performed in a particular sequence. Thus,
[(4)^2]^3/4 = [16]^3/4 = 8
is the only correct solution.
The parentheses don't force the operations to be done in that particular order. You could do what Emily did and multiply the exponents
Young Emily multiplied two times 3/4, and got 3/2. She raised 4 to the power three, getting 64. She then took its square root, getting 8i.
The problem she made was that she multiplied them and then simplified. If she multiplied two times 3/4 and got 6/4 and then raised 4 to the sixth power getting 4096. Taking the fourth root of 4096 she would have gotten the correct answer of 8. Most of the time it doesn't do any harm to simplify a fraction, however when the fraction is in the exponent, you need to be real careful before you simplify. This is an example of a case where you should not simplify.

Recommendations: 1
rev2217/norm: The standards of most programming languages, including Fortran and C/C++, explicitly forbid optimizations that fail to preserve the integrity of parentheses in order to give programmers control of the sequence of operations when it matters. Thus, such an optimization is illegal.
This is (or was) part of the FORTRAN (IV) standard; I can't say about newer FORTRANs, though I doubt it has changed. It is *not* part of the C standard, and never has been. C guarantees ordering of statements separated by &&, , ^^, and a few others, but guarantees nothing about optimization. From Harbison & Steele, Fifth Edition, Section 7.3.3, "Parenthesized Expressions": "Parentheses do not necessarily force a particular evaluation order.... The purpose of the parenthesized expression is simply to delimit the enclosed expression for grouping purposes, either to defeat the default precedence of operators or make the code more readable."
That said, I doubt that many C optimizers would apply this identity to optimize this expression.
rj

Recommendations: 0
rmhj: That said, I doubt that many C optimizers would apply this identity to optimize this expression.
P.S.: Uh, duh. C compilers *could not* optimize using this identity because there is no exponentiation operator in C. A library call(s) or algebraic identity (x * x * x) would have to be used in the original expression: the former generally couldn't/wouldn't be optimized out, and optimizations of the latter shouldn't affect the correctness.
rj

Recommendations: 0
prime13,
The parentheses don't force the operations to be done in that particular order. You could do what Emily did and multiply the exponents
Wrong. In an algebraic expression, the presence of parentheses mean that what's inside the parentheses must be evaluated and treated as a unit in evaluating what's outside of them. If that were not the case, you could simply drip the parentheses from 3*(3+1) and get ten rather than twelve.
The problem she made was that she multiplied them and then simplified. If she multiplied two times 3/4 and got 6/4 and then raised 4 to the sixth power getting 4096. Taking the fourth root of 4096 she would have gotten the correct answer of 8. Most of the time it doesn't do any harm to simplify a fraction, however when the fraction is in the exponent, you need to be real careful before you simplify. This is an example of a case where you should not simplify.
No, that also is not valid. The expression x^(6/4( does not mean that one can take the fourth root of the sixth power of x. It means that one should take the 6/4 = 3/2 power of x.
The problem here is that the rearrangement of (x^2)^(3/4) is the same as x^(6/4) only if x is either a positive real value nor zero. This is immediately obvious if you consider the possibility that x is a vector, in which case x^2 is the square of its magnitude, and thus a scalar. In fact, the 6/4 power of a vector makes no sense at all.
Norm.


