• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 83 subscribers
  • Views 799 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-F28379D: __sinpuf32()

Bui Van Linh
Intellectual 660 points
Part Number: LAUNCHXL-F28379D


Hello experts,

documentation for sinpuf32():

According to the documentation I must have:

__sinpuf32(0.75) = __sinpuf32(1.75) = __sinpuf32(2.75) = ...
__sinpuf32(-0.75) = __sinpuf32(-1.75) = __sinpuf32(-2.75) = ...

__sinpuf32(0.04798) = __sinpuf32(1.04798) = __sinpuf32(2.04798) = ...
__sinpuf32(-0.04798) = __sinpuf32(-1.04798) = __sinpuf32(-2.04798) = ...

But it is not so.

It is clear to me that __sinpuf32() can never return the exact result. But sin(x) is not equal to sin(2PI + x). It is hard to accept.
Can someone explain to me where the inaccuracy comes from?

Thanks a lot - Bui

  • 0
    Prodigy 60 points

    What you're seeing are the limitations of floating point number representation.

    From your example: 0.04798 is represented in single precision float as 0x3D4486AD. Because of limitations of a 32-bit float, the exact value of that float is actually 0.0479799993336200714111328125. The error in this case is -6.663799285888671875E-10.

    So for 1.04798, it is represented in float as 0x3F862435. The exact value represented by that float is 1.04797995090484619140625, with the error of -4.909515380859375E-8.

    Again for 2.04798, float is 0x4003121B, exact number 2.0479800701141357421875, error 7.01141357421875E-8.

    As you can see, because higher numbers represented in float take up more bits before the floating decimal point, fewer bits remain to represent the fractional part of the number, so the overall error is growing with bigger numbers.

    If we evaluate the results that you put in the comments:

    0.296921581 = 0x3E98061B

    0.296921283 = 0x3E980611

    0.296921998 = 0x3E980629

    The error between the first two is merely 2.98E-7, and -7.15E-7 between 2nd and 3rd. I.e. the lowest 5 bits of the floating point number.

    That's more than sufficiently accurate for any kind of regulation that is going to be running on these microcontrollers. If you expect more precision, you really should be looking at microcontrollers that have a double precision FPU inside.

    P.S. Single precision floating point constants should be written as 0.1234f in code. Compilers will normally parse the numbers as double precision floats, if you omit the trailing 'f'.

  • +1 in reply to David Jereb
    Intellectual 660 points

    Thank you, David!