cos block error (simulink)

why is this happen?

cos(pi/2) = 6.123e-17??

Answer 1

[John D'Errico]

Welcome to the wonderful, wacky world of floating point arithmetic.

Is the number

format long g
pi/2

ans = 
           1.5707963267949

EXACTLY pi/2?

cos(pi/2)

ans = 
      6.12323399573677e-17

Of course not. Pi is an irrational number (even subtly worse, transcendental), so it cannot ever be represented exactly in double precision arithmetic, so not in any finite number of digits. And that means pi/2 as stored is just a tiny bit off from the exact value of pi/2. Consequently, cos(pi/2) is not EXACTLY zero. Close. To within floating point trash. But not exactly so.

If you want MATLAB to work in exact multiples of pi, you can do so, but that requires using the symbolic toolbox.

sym(pi/2)

ans = 

cos(sym(pi/2))

ans = 

0

[기범]

thank you for reply.

actually,

I'm using angle conversion....

please help me......

[기범]

how can I set symbolic toolbox in simulink?

[John D'Errico]

Why do you think you need to do that? Is not 6.12323399573677e-17 close enough to zero for you? Simulink uses floating point arithmetic for its computaitons. Even if you could use syms in simulink, it would now become VERY slow. And then you would be complaing that simulink is too slow.

Intead, you need to learn to use tolerances. Rather than compariing numbers to exactly zero, you need to test if they are within some tolerance of zero. Something like:

abs(x) <= 1e-16

[기범]

Im using cos for my Quaternion,

so I need an exact value.

6.123e-17 will make error for my Quaternion.

I dont want my system slow down as you said.

Can i set 6.123e-17 to Zero in simulink?

ex) below 1*e-10 to Zero

[John D'Errico]

So you would want a rather poor approximation to the cosine function for small values? That is, you would rather see an error of 1e-10, than an error of 1e-17? Why do I feel that is just a really, really, seriously bad idea? You want an exact value some of the time, but far more often, you are willing to accept a really poor approximation?

You could test to see if the absolute value is less then 1e-16, and if so, set that to zero. At last then you are not making a rather large error.

Answer 2

[Paul]

Base Simulink doesn't have a block that implements functions cosd or cospi. Maybe some other toolbox does. If not, both of those functions support code generation so you can use the Matlab Function block and call either (or both of them) from there.

[Paul]

Does the Spherical to Cartesian block come with Simulink or one of the toolboxes or blocksets from the Mathworks? If so, please provide a link to the doc page. If not, do you have access to the block implementation?

[기범]

sorry I cannot find links.

you can add spherial to cartesian block and click help.

sorry for can't provide links

[Paul]

I couldn't add it because I couldn't find it, which is why I asked for the doc page. Did you find that block in one of The Mathworks products in the Simulink Library browswer? If so, which one?

Anyway, if you want to use degrees instead of radians in your model, it looks like you can implement the three equations in that block in your own Matlab Function using cosd and sind.

[기범]

For your recommend,

Im using MATLAB FUNCTION.

error : 1. The 'sym' class does not support code generation.

2. defined function or variable 'phirad'. The first assignment to a local variable

determines its class.

can u help me?

[Paul]

I never said to use syms. I did say to use cosd, etc. if you want have all your angles defined in degrees. So, if theta, phi, and psi are all in degrees on input, then we have

x = r.*sind(phi).*cosd(theta)

and similar for y and z