1

In the XC16 compiler's DSP routines header (dsp.h) there are these lines:

/* Some constants. */
#ifndef PI                              /* [ */
#define PI 3.1415926535897931159979634685441851615905761718750 /* double */
#endif  /* ] */
#ifndef SIN_PI_Q                                /* [ */
#define SIN_PI_Q 0.7071067811865474617150084668537601828575134277343750
                                                /* sin(PI/4), (double) */
#endif  /* ] */

But, the value of PI is actually (to the same number of decimal places) is:

3.1415926535897932384626433832795028841971693993751

The dsp.h-defined value starts to diverge at the 16th decimal place. For double floating point operations, this is borderline significant. For Q15 representations, this is not significant. The value of sin(pi/4) also diverges from the correct value at the 16th decimal place.

Why is Microchip using the incorrect value? Is there some esoteric reason related to computing trig function values, or is this simply a mistake? Or maybe it does not matter?

EBlake
  • 735
  • 7
  • 14
  • 2
    nasa apparently uses 16 digits for pi for spacecraft control, and since they (usually) don't miss their targets, I wouldn't be worried... – Marc B Jun 24 '15 at 19:42

2 Answers2

2

It turns out that both:

3.1415926535897931159979634685441851615905761718750

and

3.1415926535897932384626433832795028841971693993751

when converted to double (64bit float) are represented by the same binary number:

3.14159265358979311599796346854
(0x400921FB54442D18)

So it makes no difference in this case.

As for why they use a different number? Not all algorithms that generates PI produces it digit-by-digit. Some produce a series of numbers that merely converges to pi instead of producing one digit at a time. A good example of this is fractional values of PI. 22/7, 179/57, 245/78, 355/113 etc. all get closer and closer to PI but they don't do it digit-by-digit. Similarly, the polygon approximation method that's popular because they can be easily calculated by computer programs can calculate successive numbers that get closer and closer to PI but don't do it digit by digit.

slebetman
  • 109,858
  • 19
  • 140
  • 171
  • Note that 3.14159265358979311599796346854 is the absolute closest you can get to PI in 64 bit IEEE floating point format. If you need a better approximation then you need to use a 128bit float (well, you can invent a 96 bit float but I'm not sure that's standard) – slebetman Jul 05 '15 at 12:50
  • If both values produce the same IEEE coding, why not use the correct value? It's not as if Microchip had to go and calculate a value - the value of pi is well-documented :) – EBlake Jul 06 '15 at 16:08
  • @EBlake: The point is, both are "correct" values. It's just one is correct in a digit-by-digit sort of way and another is correct in that it approaches PI in its approximation. – slebetman Jul 06 '15 at 20:23
0

Sometimes such values are tweaked to force rounding to the machine number. 17 (including before the comma) significant places is where double get imprecise(and the operations in the compiler to calculate the value with limited precision might even worsen it)

So library programmers might have manipulated the value to ensure rounding to the "really" from the decimal representation in the source to the nearest binary number.

The test would be to write the number out in binary, and probably after the first 52 digits the remaining digits would be zero.

IOW this is a best binary representation of the 16-19 digit decimal pi number converted back to decimal, which can yield additional digits.

Marco van de Voort
  • 25,628
  • 5
  • 56
  • 89