This patch adds tau as a macro in math.h. This should allow for efficiency
improvements as higher level math functions will inevitably be refactored away from using 2pi. http://tauday.com/ for more details and examples on how to replace pi, and why using pi is in the wrong paradigm. Thanks, -Adam Talsma --- math.h 2013-01-27 23:35:53.377637077 -0800 +++ math.h.tau 2013-01-28 00:02:40.721703715 -0800 @@ -364,6 +364,7 @@ # define M_2_SQRTPI 1.12837916709551257390 /* 2/sqrt(pi) */ # define M_SQRT2 1.41421356237309504880 /* sqrt(2) */ # define M_SQRT1_2 0.70710678118654752440 /* 1/sqrt(2) */ +# define M_TAU 6.28318530717958647692 /* tau */ #endif /* The above constants are not adequate for computation using `long double's. @@ -383,6 +384,7 @@ # define M_2_SQRTPIl 1.128379167095512573896158903121545172L /* 2/sqrt(pi) */ # define M_SQRT2l 1.414213562373095048801688724209698079L /* sqrt(2) */ # define M_SQRT1_2l 0.707106781186547524400844362104849039L /* 1/sqrt(2) */ +# define M_TAU 6.283185307179586476925286766559005768L /* tau */ #endif |
On 01/28/2013 09:18 AM, Adam Talsma wrote:
> This patch adds tau as a macro in math.h. Is this part of any standard? -- Florian Weimer / Red Hat Product Security Team |
In reply to this post by Adam Talsma
On Mon, Jan 28, 2013 at 12:18:20AM -0800, Adam Talsma wrote:
> This patch adds tau as a macro in math.h. This should allow for efficiency > improvements as higher level math functions will inevitably be refactored away > from using 2pi. What exact improvements it has over using 2 * M_PI ? Multiplication by two just changes the exponent of the constant, not the mantissa (as M_PI is not subnormal nor too large), so it is exactly as precise as this. M_TAU isn't standardized (and, btw, you got your patch wrong, there was no l suffix in the second snippet), you are free to define it in whatever project you prefer to use a constant like that. > --- math.h 2013-01-27 23:35:53.377637077 -0800 > +++ math.h.tau 2013-01-28 00:02:40.721703715 -0800 > @@ -364,6 +364,7 @@ > # define M_2_SQRTPI 1.12837916709551257390 /* 2/sqrt(pi) */ > # define M_SQRT2 1.41421356237309504880 /* sqrt(2) */ > # define M_SQRT1_2 0.70710678118654752440 /* 1/sqrt(2) */ > +# define M_TAU 6.28318530717958647692 /* tau */ > #endif > > /* The above constants are not adequate for computation using `long double's. > @@ -383,6 +384,7 @@ > # define M_2_SQRTPIl 1.128379167095512573896158903121545172L /* 2/sqrt(pi) */ > # define M_SQRT2l 1.414213562373095048801688724209698079L /* sqrt(2) */ > # define M_SQRT1_2l 0.707106781186547524400844362104849039L /* 1/sqrt(2) */ > +# define M_TAU 6.283185307179586476925286766559005768L /* tau */ > #endif Jakub |
In reply to this post by Adam Talsma
The M_* constants are conditional on [__USE_BSD || __USE_XOPEN], plus
[__USE_GNU] long double versions; nothing should be added that's not in those standards. If a future version of POSIX adds a new M_* constant (whether XSI-conditional or otherwise), then glibc would add it under appropriate conditions for that version of POSIX (and, as needed, a long double version under __USE_GNU), not in the existing block of values. I don't believe it's appropriate to add new constants otherwise, especially not when, as noted, they are trivially derived from other constants already present with no loss of accuracy. -- Joseph S. Myers [hidden email] |
Free forum by Nabble | Edit this page |