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.

PI = 4.0 * atan(1.0) yields 3.370281e+12

Other Parts Discussed in Thread: MSP430F2619

Here is my entire program:

#include <msp430f2619.h>
#include <math.h>
#include <stdbool.h>
#include "msp430.h"
#include "main.h"

double PI;

void main(void)
{
    msp430Init();                           // initialize the hardware
    PI = 4.0 * atan(1.0);                // initialize Pi
}

Executing this program yields the value 3.370281e+12 for PI.  This seems off by more than a little bit.

CCSv5, TI v4.1.1 compiler, lnk_msp430f2619.cmd, <automatic> run-time support

Anyone have a suggestion as to how to get a better value for Pi than 355/113?

  • Oops, that's really a little bit off.  With TIs compiler 4.1.2 I'm getting 3.141593.

    Although this is not really helpful, if I were you, I would use 355.0 / 113.0.  Or even better 103993.0 / 33102.0 (see http://en.wikipedia.org/wiki/Pi).

    My guess is, that this is not really a library problem, perhaps more a setup/configuration problem.

    What does PI show before it gets "4.0 * atan(1.0)" assigned and what BTW does PI show after you assign "355.0/113.0"?

    Hardy

  • I checked for updates and installed the 4.1.2 compiler.  I got the following results when I recompiled and ran it again

        PI = 4.0 * atan(1.0);    // 3.370281e+12
        PI = 355.0 / 113.0;        // 1.185498e+34

    Any ideas?

  • Jim Taylor said:
        PI = 4.0 * atan(1.0);                // initialize Pi

    I don't think this is a good idea. SInce most likely atan is using an internal version of PI to return its value. atan(1) is 45deg, which is equivalent to (45/360)*2*PI = 1/4 PI. So you're most likely twisting PI through some slow and lossy calculations to get PI.
    If PI isn't directly provided by the same library that gives you atan, then 355.0/113.0 gives you a really close substitute (precise to 7 digits).
    However, "355/113" (without ".0") will give you 3.0, as this is an integer division that is turned to double when assigning it. :)

  • I would expect atan to use a Hastings approximation or a series expansion to return atan(1.0).  I don't really need to get PI that way.  I can type in a more precise value from memory.  I'm just trying to find out if I can trust the compiler/runtime combination.  It appears I can't.

  • Jim Taylor said:
    I'm just trying to find out if I can trust the compiler/runtime combination.  It appears I can't.

    Unless the result you posted has a different reason, then you apparently cannot.
    However, your explanation of atan (I'm not a member of the theoretical math faction) would explain why your PI is so far off: rounding errors during the approximation algorithm. The MSP doesn't use (simply doesn't have the power) for high-precision floating point operations. I must admit that I rarely use any floating point. In most cases it can be broken down to integer math with sufficient precision and high speed.
    Simply using doubles for everything, as it is commonly done on PCs with their highly-optimized match coprocessor, easily makes one forget the physical limitations.

  • Jim,

    I'm not a CCS user, but I think they let you pick the size of your double-precision floats.  Often embedded systems use 32-bit floats for both single and double precision, but the tools usually let the developer make that choice.

    I'm thinking there is a conflict between your compiler settings and your runtime float support.  For example, the compiler might be expecting 64-bit doubles but the linker links in the runtime that uses 32-bit doubles.

    Is the linker giving you any warnings? Have you customized the linker command file or have you told CCS to use a particular one?

    Are there choices in the project configuration regarding the size of double-precision floats?

    Jeff

  • It appears that you're right. 

    The compiler is perfectly happy with doubles, but the runtime doesn't seem to have any idea what the compiler is talking about.

    I recoded the example using float instead of double and it works

    /*
     * main.c
     */
    #include <math.h>

    void main(void)
    {
        float Pi_One;
        float Pi_Two;
        float placeholder;

        Pi_One = 4.0 * atanf(1.0);             // 3.141593
        Pi_Two = 355.0 / 113.0;                    // 3.141593
        placeholder = Pi_One / Pi_Two;    // 0.999998

    }



  • Jim Taylor said:
    The compiler is perfectly happy with doubles, but the runtime doesn't seem to have any idea what the compiler is talking about.

    I think the problem is with how the debugger displays doubles, rather than the runtime support. e.g. I compiled the following with CCS V5.2.1.00018 and MSP430 compiler V4.1.2:

    #include <msp430f2619.h>
    #include <math.h>
    #include <stdbool.h>
    #include "msp430.h"
    #include <stdio.h>

    double PI;

    void main(void)
    {
        WDTCTL = WDTPW + WDTHOLD;
        PI = 4.0 * atan(1.0); // initialize Pi
        printf ("PI = %.14g\n", PI);
    }


    The debugger Expression view reported the incorrect value of 3.370281e+12 for PI. However, the printf output generated by the running code showed the correct result:

    PI = 3.1415926535898

  • Debugging the same program in CCS 5.3.0.00042 (BETA), still compiling with MSP430 compiler V4.1.2, the expression view in the debugger now shows the correct value of the double PI. i.e. the problem has been fixed in CCS 5.3 BETA. The list of bug fixes in the release notes for v5.3.0 Beta1 includes:

    SDSCM00044133     IDE     MSP430     double types not displayed properly in the Locals/Expressions view for hexadecimal formats

**Attention** This is a public forum