c math.h

c - ¿Por qué math.h define pi, pi/2, 2/pi pero no 2*pi?



(2)

¿Es 2 * M_PI tan difícil de escribir?

Sin embargo, en serio, una vez, cuando la gente se preocupaba por compiladores simples que no podían hacer el plegado constante y la división era prohibitivamente costosa, en realidad tenía sentido tener un PI / 2 constante en lugar de arriesgarse a una división en tiempo de ejecución. En nuestro mundo moderno, uno probablemente solo definiría M_PI y lo llamaría un día, pero las otras variantes viven para la compatibilidad hacia atrás.

Esta es una pregunta realmente simple: ¿Por qué hay constantes predefinidas para pi, pi / 2, pi / 4, 1 / pi y 2 / pi pero no para 2 * pi? ¿Hay una razón más profunda detrás de esto?

Esta pregunta no es sobre todo el debate pi vs tau . Me pregunto si hay una razón técnica para implementar ciertas constantes pero no otras. Puedo pensar en dos posibilidades:

  1. Evitando errores de redondeo.
  2. Evitar divisiones en tiempo de ejecución que podrían ser más caras.

Esto es sólo mi suposición.

Supongo que estas constantes están relacionadas con las implementaciones de diferentes funciones en la biblioteca matemática:

ck@c:~/Codes/ref/glibc/math$ grep PI *.c s_cacos.c: __real__ res = (double) M_PI_2 - __real__ y; s_cacosf.c: __real__ res = (float) M_PI_2 - __real__ y; s_cacosh.c: ? M_PI - M_PI_4 : M_PI_4) ... s_clogf.c: __imag__ result = signbit (__real__ x) ? M_PI : 0.0; s_clogl.c: __imag__ result = signbit (__real__ x) ? M_PIl : 0.0; ck@c:~/Codes/ref/glibc/math$

M_PI , M_PI_2 y M_PI_4 aparecen con bastante frecuencia, pero no hay 2.0 * M_PI . Entonces, para la pregunta original de Hanno, creo que MvanGeest tiene razón --- 2π no es tan útil, al menos para implementar libm .

Ahora sobre M_PI_2 y M_PI_4 , sus existencias están bien justificadas. La documentación de la biblioteca GNU C sugiere que "estas constantes provienen del estándar Unix98 y también estaban disponibles en 4.4BSD". Los compiladores no eran tan inteligentes en ese momento. Escribir M_PI/4 lugar de M_PI_4 puede causar una división innecesaria. Aunque los compiladores modernos pueden optimizar eso (gcc usa mpfr desde 2008, por lo que el redondeo uniforme se realiza correctamente), el uso de constantes numéricas es una forma más portátil de escribir código de alto rendimiento.