0

I am solving 3 linear algebraic equations using MATLAB. I know the expected solutions, one of which should be 0 but it's showing 2.2204e-16.

MATLAB Code:

a=[2 5 -3; 9 2 3; 7 -12 5]
b=[-11; 0; 8]
x=inv(a)*b

The expected solution is -1, 0, 3, but it shows:

-1.0000e+00
2.2204e-16
3.0000e+00

Technically, I didn't use the MATLAB software for this, but rather used this online Octave interpreter.

I expect exactly 0 as the output, not 2.2204e-16. How should I approach this?

Dev-iL
  • 23,742
  • 7
  • 57
  • 99
partho
  • 1,101
  • 2
  • 21
  • 37
  • This is called "machine precision".. See [this post](http://stackoverflow.com/q/686439/3372061) for more information. – Dev-iL Jan 21 '17 at 07:55
  • Yes, that solved !! – partho Jan 21 '17 at 07:57
  • 2
    @SandipanDey That's some dangerous advice, because if the output of the division is some _legit_ decimal number - this information will be lost. @partho - if you _must_ round it, do so using a known amount of degrees of precision - `round(...,N)` where `N` of about 6 should do in your case. However, the problem is that you're using the wrong operators for solving a linear equation.... I'll post an answer shortly. – Dev-iL Jan 21 '17 at 08:02
  • @Dev-iL , Yes that might be dangerous in some cases, then how to approach? – partho Jan 21 '17 at 08:06

1 Answers1

6

What you are seeing is a result that is correct up to machine precision (the number you're getting is actually eps(1) or eps('double')).

For solving linear equations such as the one in your example, matrix division should be used. These functions are mldivide, \ and mrdivide, / (you are encouraged to read their docs).

When using these operators MATLAB (or Octave) chooses the right solver to use, depending on the properties of the inputs. These solvers don't invert a explicitly (at least not the solvers whose docs I read), which is done to make the solution faster, more accurate, more numerically stable, or a combination thereof. For an example of how how inversion is avoided, check out the documentation of the LU solver.

For example:

a=[2 5 -3; 9 2 3; 7 -12 5];
b=[-11; 0; 8];
x=a\b

Yields:

x =

    -1
     0
     3
Dev-iL
  • 23,742
  • 7
  • 57
  • 99
  • I don't believe the Octave solver (or MATLAB solver) will identify that an output needs to be an integer. Not calculating the inverse explicitly is the main source of improved precision. – stephematician Jan 23 '17 at 23:14
  • 1
    @stephematician I've removed that irresponsible claim from my answer. Thanks :) – Dev-iL Jan 24 '17 at 13:51
  • Did you cast the values to integer or leave them as doubles? I ask because with 2016a if the `format` statement is `g` or `e` I could not get `0`. It still comes down to machine precision. For example my output is `6.5521e-17` for `x(2)` with `format short e`. I do prefer this approach over `inv` though, hence +1. – Matt Jan 24 '17 at 14:12
  • @Matt The code I posted is exactly what I did - no more, no less; and casting is not a part of it... `x` is `double`, and moreover, `all(a\b == [-1;0;3])` returns `true`. Using R2016b. – Dev-iL Jan 24 '17 at 14:14
  • @Dev-iL well that is most certainly machine dependent. `a=[2 5 -3; 9 2 3; 7 -12 5];b=[-11; 0; 8];all(a\b == [-1;0;3])` returns `0` for me with 2014b, 2016a and 2016b. I am running an i7-4810MQ with Win7 64bit. – Matt Jan 24 '17 at 14:56
  • @Matt I would also expect to get your result, tbh. My system is i7-3770 Win7 x64. – Dev-iL Jan 24 '17 at 14:59