8

I started to learn GNU Octave today, and tried the first expression given in the manual

exp(i*pi)

The result is 

ans = -1.0000e+000 + 1.2246e-016i

And it seems GNU Scientific Library gives similar results too.

So is this a Octave bug, or general problems of numeric analysis software (symbolic evaluation software will definitely give an answer of exact one)?

James Mertz
  • 26,224
  • 41
  • 111
  • 163
Siyuan Ren
  • 411
  • 2
  • 5
  • 17
  • 2
    Seems octave is primaly intended for numerical analysis. Mathematica would definitely give you a better answer... :P just joking... Try searching for a GNU symbolical analysis solution – gd1 Jul 27 '11 at 15:21
  • @Giacomo: I know that. I just wonder if all numeric analytic software evaluates to such number, or just GNU Octave. – Siyuan Ren Jul 27 '11 at 16:37
  • @Karsus Ren this isn't actually a software bug, but a hardware one. It's an inherent limitation of trying to evaluate expressions with irrational numbers on hardware with a limited amount of storage for a single number. – Breakthrough Aug 03 '11 at 17:22
  • http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html – James Aug 08 '11 at 16:11

1 Answers1

8

This isn't a bug with either, but due to the way computers perform floating point operations. There is a limited amount of precision any computer can operate with, and so you will sometimes see anomalies like this. While it is possible to write software that can handle this, it would take a lot more computation time and drastically increase memory requirements.

If you look at it, e^(i*pi) returns -1 + 1.2x10^-16i. As you can see, the imaginary component is extremely small (most would consider it negligible, since it's 16 orders of magnitude smaller then the real part). This component is introduced by rounding and precision errors, both with the calculation itself, as well as the stored value of pi since it's irrational (see this link for another example dealing with irrational numbers).

If this calculation error is unacceptable, you should look into math packages which perform symbolic rather then numerical analysis, or ones that use high-precision floating point numbers. The caveats of these are that they will drastically increase your memory requirements, and symbolic analysis is often much slower. Also, higher precision numbers will just shrink the magnitude of the rounding/precision errors, not eliminate them.

Breakthrough
  • 34,227
  • 10
  • 105
  • 149
  • 1
    I just need a confirmation that this is the common behavior of numerical analysis software. – Siyuan Ren Aug 04 '11 at 10:15
  • @Karsus Ren it's actually behaviour of this kind of software with *high enough precision*. I know that seems counter-intuitive, but lower precision numbers don't return these anomalies as often. See [this article from Microsoft](http://support.microsoft.com/kb/125056) for more details, but remember, this issue is a combination of both the source code and the compiler/target architecture. Also, [this Wikipedia article](http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems) has some good background information on the problem. – Breakthrough Aug 04 '11 at 10:40
  • 1
    The underlying problem is that Octave's constant `pi` is not the mathematical constant `π`, but a close floating-point approximation to it. The `exp` function adds another small error to that. A system that works with *symbolic* expressions could compute `exp(i*pi)` exactly; Octave is not such a system. – Keith Thompson Jul 11 '12 at 08:08