If I understand correctly. This means the symbolic processor calculated an approximate solution |
No. The symbolic processor does not calculate the inverse the same way as the numeric processor. I said I didn't know how it did calculate it, but that was a dumb statement on my part. It does it the same way it does everything, which is by first rearranging the expression (i.e. symbolic math), and then simplifying (although maybe in practice it does this in more than just two stages; I'm not sure about that). So as a simpler example for a 3x3 matrix, see the attached worksheet. First it rearranges the expression. The fact that in your case the elements of the expression are floating point numbers is irrelevant. Then is simplifies. During the simplification step, since you have floating point numbers, it calculates each element of the inverse matrix using 20 digits of precision. You could increase or decrease that precision using the float keyword.
| however the numeric could not reach a convergence since it requires higher precision! |
It's not a question of what is required. The numeric processor uses about 16 digits of precision. That's what is available to it. According to the help it calculates the inverse using LU decomposition, which is a modified form of Gaussian elimination.
Anyway, the point is moot because the inverse is not the problem. It can't converge when it tries to calculate TM(n). If you right click and trace the error you will find it can't calculate one of the derivatives (not enough time to figure out why; sorry).
It is weird that the numeric uses Gauss elmination since this is the recommended way of solving it (according to literature) |
If it's the recommended way of solving it why do you think it's weird that that's the way it does it?
