c++ 17
¿C++ 11, 14, 17 o 20 introduce una constante estándar para pi? (6)
Hay un problema bastante tonto con el número pi en C y C ++.
Hasta donde sé,
M_PI
definido en
math.h
no es requerido por ningún estándar.
Los nuevos estándares C ++ introdujeron una gran cantidad de matemáticas complicadas en la biblioteca estándar: funciones hiperbólicas,
std::hermite
y
std::cyl_bessel_i
, diferentes generadores de números aleatorios, etc.
¿Alguno de los ''nuevos'' estándares trajo una constante para pi? Si no, ¿por qué? ¿Cómo funciona toda esta complicada matemática sin ella?
Soy consciente de preguntas similares sobre pi en C ++ (tienen varios años y estándares de edad); Me gustaría saber el estado actual del problema.
También estoy muy interesado en por qué oh por qué C ++ todavía no tiene una constante pi pero tiene muchas matemáticas más complicadas.
UPD: Sé que puedo definir pi yo mismo como 4 * atan (1) o acos (1) o doble pi = 3.14. Por supuesto. ¿Pero por qué en 2018 todavía tengo que hacerlo? ¿Cómo funcionan las funciones matemáticas estándar sin pi?
Como otros dijeron, no hay
std::pi
pero si quieres un valor
PI
preciso puedes usar:
constexpr double pi = std::acos(-1);
Esto supone que su implementación de C ++ produce un valor correctamente redondeado de PI de
acos(-1.0)
,
que es común pero no está garantizado
.
No es
constexpr
, pero en la práctica, la optimización de compiladores como gcc y clang lo evalúa en tiempo de compilación.
Sin embargo, declarar que es
const
es importante para que el optimizador haga un buen trabajo.
Editado: para eliminar el término necesario, porque resultó controvertido. Es demasiado de un término absoluto.
C ++ es un lenguaje grande y complejo, por eso el Comité de Estándares solo incluye cosas que son
muy necesarias
.
En la medida de lo posible, se deja a las bibliotecas estándar sin lenguaje ... como Boost.
boost::math::constants
No, pi todavía no es una constante introducida en el lenguaje, y es un dolor en el cuello.
Soy afortunado porque uso Boost (www.boost.org) y definen
pi
con una cantidad suficientemente grande de decimales para incluso un
long double
128 bits de
long double
.
Si no usa Boost, codifíquelo usted mismo.
Definirlo con una función trigonométrica es tentador, pero si lo hace, no puede convertirlo en un
constexpr
.
La precisión de las funciones trigonométricas tampoco está garantizada por ningún estándar que conozca (
cf.
std::sqrt
), por lo que realmente se encuentra en un terreno peligroso, confiando en tal función.
Hay una manera de obtener un valor
constexpr
para
pi
mediante metaprogramación: consulte
http://timmurphy.org/2013/06/27/template-metaprogramming-in-c/
Obviamente, no es una buena idea porque no hay un tipo obvio con el que definir pi que sea universalmente aplicable en todos los dominios.
Pi es, por supuesto, un número irracional, por lo que no puede ser representado correctamente por
ningún
tipo de C ++.
Podría argumentar que el enfoque natural, por lo tanto, es definirlo en el tipo de punto flotante más grande disponible.
Sin embargo, el tamaño del tipo de coma flotante estándar más grande
long double
no está definido por el estándar C ++, por lo que el valor de la constante variaría entre los sistemas.
Peor aún, para cualquier programa en el que el tipo de trabajo no fuera el más grande, la definición de pi sería inapropiada ya que impondría un costo de rendimiento en cada uso de pi.
También es trivial para cualquier programador encontrar el valor de pi y definir su propia constante adecuada para su uso, por lo que no ofrece ninguna gran ventaja incluirlo en los encabezados matemáticos.
M_PI
se define por "un estándar", si no es un estándar de
lenguaje
:
POSIX
con la extensión X / Open System Interfaces (que es muy comúnmente compatible y requerido para la marca oficial de UNIX).
(Todavía) no está seguro de lo que habrá en C ++ 20, pero como usted preguntó: probablemente tendrá tales constantes . Library Evolution aprobó el documento de la versión anterior (con espacios de nombres y plantillas variables) en noviembre de 2018, y podría aparecer en el Borrador del Comité en agosto de 2019.