Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Lately I've been trying to brush up on the math I should have learned in high school. (I didn't pay much attention.) Regarding this, college entrance exams and octave make a great pair.

This morning I got to fractional powers. And octave had something surprising in store:

octave:41> (9 ^ 1/2)
ans =  4.5000
octave:42> (9 ^ .5)
ans =  3
octave:43> (9 ^ 0.5)
ans =  3

Maybe I dozed off when we covered this in high school, but no... According to this website,

By the way, some decimal powers can be written as fractional exponents, too. If you are given something like "35.5", recall that 5.5 = 11/2, so:

3 ^ 5.5 = 3 ^ 11/2

So evidently there's some reason why octave evaluates these two expressions differently...

Why does octave evaluate fractional powers differently? Is this a non-feature, or is there a good reason why it should?

share|improve this question
PEMDAS (purplemath.com/modules/orderops.htm) is taught in many schools, and it's what I learned, so it's a bit frustrating that octave does not follow it. Although, I guess in a sense it does follow PEMDAS, it just requires us to ignore the years we have already spent learning to treat fractions as entities in their own right.. hmm... If I were the world's benevolent dictator, there are only two things I would change, and the way mathematics is taught in schools would be one of them. – ixtmixilix Apr 16 '12 at 19:48
up vote 4 down vote accepted

I'm no Octave expert, but it look like Octave parses "9 ^ 1/2" as "(9^1)/2". That is, the exponentiation operator has a higher priority (binds tighter) than division. Try parenthesizing like this: "(9 ^ (1/2))".

share|improve this answer
that does the trick! thank you. – ixtmixilix Apr 6 '12 at 12:44
Good catch, Bruce. Still, there's a broader trap here. 9 ^ 1/2 is an exact value, and can be reduced losslessly to 3 by any sane CAS. A CAS may treat 0.5 as a floating-point value, however, rather than try to keep an exact representation of it. I tried to get Octave to show this, and failed. I don't know if that means it always uses FP or if it's uncommonly smart about exact representation, or I just didn't find the right corner case. But for example, my HP 49g+ will return a residual if you subtract (9^0.3) from (9^(1/3)), and 0 when you subtract (9^0.5) from (9^(1/2)). Be careful! – Warren Young Apr 6 '12 at 20:12
Actually, your broader trap was what I thought the problem was at first. I had to read the question several times to figure it out. Without examining Octave in detail, it look like it always uses FP, but that's a total guess. – Bruce Ediger Apr 6 '12 at 20:27
Thinko: I meant (9^(0.8))-(9^(4/5)) in my 49g+ example. I was also playing around with (9^0.3333333...)-(9^(1/3)), but it's no surprise that that gives a residual. The surprise is that FP often has roundoff errors with surprisingly short rational numbers like 0.8. FP stores integers exactly; best to assume anything fractional is stored imprecisely. – Warren Young Apr 6 '12 at 21:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.