math constants
Locked
 
|
Hello Luigi, all,
I had a typo in my code and used M_SQRT_2 instead of M_SQRT2, the former being defined as 1 / sqrt(2), but what I wanted was sqrt(2). We also have a macro M_SQRT1_2 with the same value and which seems to have a better name. I find M_SQRT_2 quite confusing and non-intuitive, so I am wondering if we could just deprecate it and remove it in one of the next versions ? There are also some constants whose meaning does not appear crystal-clear at first sight (M_IVLN10, M_LN2LO, M_LN2HI, M_INVLN2). Can someone provide a definition, so that we can maybe add them to the source ? Finally there are some constants with many digits (M_SQRT1_2, M_PI). Since there is no specifier (L) I guess they are always mapped to double by the compiler, which should be 64bit on every platform, so effectively they won't help even if one uses them to initialize a __float128 etc. ? Maybe we should rather do it like GNU and add versions of the macros like M_PIl, M_SQRT1_2l defining more digits and with the L suffix ? Then we would also be in line with gcc. What do you think ? Best regards Peter ------------------------------------------------------------------------------ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Yes, it might make sense. But truth be told, I'd be for having less of them rather than more. Which of the macros are already defined by the compilers we support? Luigi On Wed, Nov 4, 2015 at 10:38 AM Peter Caspers <[hidden email]> wrote: Hello Luigi, all, -- <http://leanpub.com/implementingquantlib> ------------------------------------------------------------------------------ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
this is what is shipped with gcc
/* Some useful constants. */ #if defined __USE_MISC || defined __USE_XOPEN # define M_E 2.7182818284590452354 /* e */ # define M_LOG2E 1.4426950408889634074 /* log_2 e */ # define M_LOG10E 0.43429448190325182765 /* log_10 e */ # define M_LN2 0.69314718055994530942 /* log_e 2 */ # define M_LN10 2.30258509299404568402 /* log_e 10 */ # define M_PI 3.14159265358979323846 /* pi */ # define M_PI_2 1.57079632679489661923 /* pi/2 */ # define M_PI_4 0.78539816339744830962 /* pi/4 */ # define M_1_PI 0.31830988618379067154 /* 1/pi */ # define M_2_PI 0.63661977236758134308 /* 2/pi */ # 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) */ #endif /* The above constants are not adequate for computation using `long double's. Therefore we provide as an extension constants with similar names as a GNU extension. Provide enough digits for the 128-bit IEEE quad. */ #ifdef __USE_GNU # define M_El 2.718281828459045235360287471352662498L /* e */ # define M_LOG2El 1.442695040888963407359924681001892137L /* log_2 e */ # define M_LOG10El 0.434294481903251827651128918916605082L /* log_10 e */ # define M_LN2l 0.693147180559945309417232121458176568L /* log_e 2 */ # define M_LN10l 2.302585092994045684017991454684364208L /* log_e 10 */ # define M_PIl 3.141592653589793238462643383279502884L /* pi */ # define M_PI_2l 1.570796326794896619231321691639751442L /* pi/2 */ # define M_PI_4l 0.785398163397448309615660845819875721L /* pi/4 */ # define M_1_PIl 0.318309886183790671537767526745028724L /* 1/pi */ # define M_2_PIl 0.636619772367581343075535053490057448L /* 2/pi */ # 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) */ #endif On 13 November 2015 at 17:31, Luigi Ballabio <[hidden email]> wrote: > Yes, it might make sense. But truth be told, I'd be for having less of them > rather than more. Which of the macros are already defined by the compilers > we support? > > Luigi > > > On Wed, Nov 4, 2015 at 10:38 AM Peter Caspers <[hidden email]> > wrote: >> >> Hello Luigi, all, >> >> I had a typo in my code and used M_SQRT_2 instead of M_SQRT2, the >> former being defined as 1 / sqrt(2), but what I wanted was sqrt(2). We >> also have a macro M_SQRT1_2 with the same value and which seems to >> have a better name. I find M_SQRT_2 quite confusing and non-intuitive, >> so I am wondering if we could just deprecate it and remove it in one >> of the next versions ? >> >> There are also some constants whose meaning does not appear >> crystal-clear at first sight (M_IVLN10, M_LN2LO, M_LN2HI, M_INVLN2). >> Can someone provide a definition, so that we can maybe add them to the >> source ? >> >> Finally there are some constants with many digits (M_SQRT1_2, M_PI). >> Since there is no specifier (L) I guess they are always mapped to >> double by the compiler, which should be 64bit on every platform, so >> effectively they won't help even if one uses them to initialize a >> __float128 etc. ? Maybe we should rather do it like GNU and add >> versions of the macros like M_PIl, M_SQRT1_2l defining more digits and >> with the L suffix ? Then we would also be in line with gcc. >> >> What do you think ? >> >> Best regards >> Peter >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> QuantLib-dev mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > -- > > <http://leanpub.com/implementingquantlib> > <http://implementingquantlib.com> > <http://twitter.com/lballabio> ------------------------------------------------------------------------------ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |