[libcxx-commits] [PATCH] D60869: Added std::assoc_laguerre and std::laguerre [sf.cmath]

Andre Brand via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Thu Apr 18 07:37:03 PDT 2019


thebrandre created this revision.
thebrandre added a reviewer: libc++.
thebrandre added a project: libc++.

Added std::assoc_laguerre and std::laguerre from C++17, 29.9.5 Mathematical special functions [sf.cmath].

Resubmitted parts of  Added implementations of five Mathematical Special Functions added in C++17 <https://reviews.llvm.org/D58876>

Notes:

- The algorithm is the same one that is used in boost and libstdc++. Just like boost (but unlike gcc-8.3.1), I use double internally for the float implementation and long double for the double implementation. This is kind of a last resort to achieve sufficiently accurate results ... considering the large number of floating-point operations involved for large n. Otherwise, we'd get less than 1% accuracy for float even in the range n<128 targeted by the standard. That's the case in libstdc++ (with gcc-8.3.1) . (Confirmed that by comparing the results for float and long double).
- I haven't included a comparison with Visual Studio 2017 this time. It turns out, they simply use boost-1.66 internally and export the implementations in msvcp140_2.dll (which is exclusively for sf.cmath functions) to hide the boost headers. Interestingly, the special functions in boost have a lot of (partly surprising) dependencies across boost: lexical_cast, smart_ptr, preprocessor, concept_check, array, container, etc.



- The implementation is inline just like libstdc++ but unlike Visual Studio 2017. The latter thus runs into AVX-SSE transition penalties <https://software.intel.com/en-us/articles/avoiding-avx-sse-transition-penalties>: on my system, the dll being loaded (msvcp140_2.dll) is compiled without AVX and uses SSE instructions (floating-point operations usually do that). The inline implementation avoids that problem completely. One downside of the inline implementation is that we introduce a dependency of cmath on stdexcept ... which may conflict with some efforts in "freestanding"?



- I will update the related revisions to inline implementations as well ... now that I am pretty much convinced that this is the right choice.

Related revisions:

- Added std::assoc_legendre and std::legendre <https://reviews.llvm.org/D60234>
- Added implementation of expint <https://reviews.llvm.org/D60234>




Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D60869

Files:
  libcxx/include/cmath
  libcxx/test/std/numerics/c.math/cmath.pass.cpp
  libcxx/test/std/numerics/laguerre/assoc_laguerre_basic.pass.cpp
  libcxx/test/std/numerics/laguerre/assoc_laguerre_comparisons.pass.cpp
  libcxx/test/std/numerics/laguerre/assoc_laguerre_exceptions.pass.cpp
  libcxx/test/std/numerics/laguerre/laguerre_basic.pass.cpp
  libcxx/test/std/numerics/laguerre/laguerre_comparisons.pass.cpp
  libcxx/test/std/numerics/laguerre/laguerre_exceptions.pass.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D60869.195728.patch
Type: text/x-patch
Size: 74481 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-commits/attachments/20190418/b13848fe/attachment-0001.bin>


More information about the libcxx-commits mailing list