Understanding how Matlab approximations work

Question

Pl Pl 2013-4-9

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/71179-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

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

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

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

per isakson 2013-4-9

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/71179-understanding-how-matlab-approximations-work#answer_81608

在 MATLAB Online 中打开

Try

format hex

6 个评论
显示 4更早的评论隐藏 4更早的评论

Pl Pl 2013-4-9

编辑：Pl Pl 2013-4-9

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

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.

Pl Pl 2013-4-9

在 MATLAB Online 中打开

"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 2013-4-9

编辑：per isakson 2013-4-9

在 MATLAB Online 中打开

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
    >>