Understanding how Matlab approximations work

Dear all,

I have what may be a naive question about how Matlab truly works. I have an ODE whose solution lies on the unit sphere. One of the equilibrium points is (1,0,0). When I look for the equilibrium points using numerical methods, Matlab tells me that the equilibrium point is

1.000000000000000

0

0.000000000000000

When I then try to solve the equation, after some time, the solution of the equation leaves the equilibrium and starts to go around the sphere. But if before solving the equation I specify to Matlab to start from the point

1

0

0

then nothing happens (which is rather normal since the point is an equilibrium one, even if unstable). My question is therefore, why does the solution leave the equilibrium when the starting point is

1.000000000000000

0

0.000000000000000

To me, this was the exact same as

1

0

0

since I thought Matlab did not use more than 16 digits. But I am obviously wrong since the solutions are not the same... Is Matlab hiding me some numerical approximations somewhere?

Thank you very much

Answer 1

[per isakson]

Try

    format hex

[Pl Pl]

Hello,

With this format and using numerical methods to find the equilibrium point, Matlab tells me that its coordinates are

   3ff0000000000000
   0000000000000000
   3c91a62633145c07

So the first two components are correct, but the last one, I guess, does not exactly correspond to 0, although with format long the third component reads, as I said before

0.000000000000000

Any idea where this comes from? And why is the first component not an exact 1 like the second component, but

1.000000000000000

like the third one? This does not make sense to me at all...

Thanks a lot for your answers,

[per isakson]

I can only speculate:

• I assume your ODE-solver is based on numerical methods
• the ODE-solver uses a tolerance
• one should always expect rounding errors with numerical methods
• the exact solution, (1,0,0), is the exception. I guess the solver finds this solution only when it never starts doing numerical calculations
• Matlab's flint (floating point integer) might have something to do with it. 1 is flint 1.00 is not.
• to understand one has to inspect the code of the ODE-solver

[Pl Pl]

Thank you for you answer. I will try to explain again because what I would like to understand first is not related to the solver.

I know that there is an equilibrium point at (1,0,0) from analytical considerations. Even though I know the exact coordinates of this equilibrium, I used a numerical method - which is the minimization of a certain function - which returns the famous coordinates in format long

1.000000000000000

0

0.000000000000000

At this point, the ODE-solver has played no role. First question: why the three coordinates do not look the same, i.e. the first and the third contain 16 digits and the second is only a 0? I only used the Matlab function fminsearch.

Now, I have two cases:

- if I give the ODE solver

1

0

0

as a starting point, nothing happens.

- if I give the ODE solver

1.000000000000000

0

0.000000000000000

as a starting point, the solution will eventually leave the (unstable) equilibrium.

From this, it seems reasonable to infer that the second coordinates do not represent (1,0,0) but another point which is very close to it. I thought that to Matlab these two points were the exact same but this does not seem to be the case. This question is not related to the way the ODE solver actually solves the equation, but rather to the representation of the equilibrium coordinates. I understand that if the coordinates are not exactly exact, tolerances, numerical approximations and the way the solver works can make the solution leave the equilibrium or not. My question is not about why this happens but why the second set of coordinates does not represent the point (1,0,0) for which the solution stays at the equilibrium point.

I hope I made myself clear, sorry for the laborious explanations,

Thank you.

[per isakson]

"My question is not about why this happens but why the second set of coordinates does not represent the point (1,0,0) for which the solution stays at the equilibrium point."

• the hex output indicates that the two *inputs*** are indeed identical
• however, fminsearch obviously sees a difference (whatever that is)

fminsearch is implemented in m-code. With the debugger, you could step through the function with the two different inputs. That might explain what you see.

[Pl Pl]

"the hex output indicates that the two are indeed identical"

Does it? I thought on the contrary that the third component in the hex format was not as expected. To recall things, the coordinates of the equilibrium point using fminsearch in format hex are

   3ff0000000000000
   0000000000000000
   3c91a62633145c07

I thought it should read

   3ff0000000000000
   0000000000000000
   0000000000000000

shouldn't it?

I'm not sure I know how to use the debugger as you propose...

Thank you for your patience.

[per isakson]

Communication is tricky. I tried to say that the two sets of inputs are indentical. (I added the word "inputs" in my previous comment.)

    >> format hex
    >> 1,0,0
    ans =
       3ff0000000000000
    ans =
       0000000000000000
    ans =
       0000000000000000
    >> 1.0000, 0.0000, 0.0000
    ans =
       3ff0000000000000
    ans =
       0000000000000000
    ans =
       0000000000000000
    >>

Still the two outputs differ.

Did you try to step through the code?