w4kek/WSJT-X
1
0
Fork 0
mirror of https://github.com/saitohirga/WSJT-X.git synced 2026-06-16 12:48:42 -04:00
Code Issues Packages Projects Releases Wiki Activity

Squashed 'boost/' content from commit b4feb19f2

Browse Source 
git-subtree-dir: boost
git-subtree-split: b4feb19f287ee92d87a9624b5d36b7cf46aeadeb
This commit is contained in:
Bill Somerville
2018-06-09 21:48:32 +01:00
commit 4ebe6417a5
12444 changed files with 2327021 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
libs/math/doc/overview/building.qbk
+106
View File
@@ -0,0 +1,106 @@
[section:building If and How to Build a Boost.Math Library, and its Examples and Tests]
[h4 Building a Library (shared, dynamic .dll or static .lib)]
The first thing you need to ask yourself is "Do I need to build anything at all?"
as the bulk of this library is header only: meaning you can use it just by
#including the necessary header(s).
For most simple uses,
including a header (or few) is best for compile time and program size.
Refer to
[link extern_c C99 and C++ TR1 C-style Functions]
for pros and cons of using
the TR1 components as opposed to the header only ones.
The ['only] time you ['need] to build the library is if you want to use the
`extern "C"` functions declared in `<boost/math/tr1.hpp>`. To build this
using Boost.Build, from a commandline boost-root directory issue a command like:
bjam toolset=gcc --with-math install
that will do the job on Linux, while:
bjam toolset=msvc --with-math --build-type=complete stage
will work better on Windows (leaving libraries built
in sub-folder `/stage` below your Boost root directory).
Either way you should consult the
[@http://www.boost.org/doc/libs/release/more/getting_started/index.html
getting started guide] for more information.
You can also build the libraries from your favourite IDE or command line tool:
each `extern "C"` function declared in `<boost/math/tr1.hpp>` has its own
source file with the same name in `libs/math/src/tr1`. Just select the
sources corresponding to the functions you are using and build them into
a library, or else add them directly to your project. Note that the
directory `libs/math/src/tr1` will need to be in your compiler's
#include path as well as the boost-root directory
(MSVC Tools, Options, Projects and Solutions, VC++ Directories, Include files).
[note If you are using
a Windows compiler that supports auto-linking and you have built the sources
yourself (or added them directly to your project) then you will need to
prevent `<boost/math/tr1.hpp>` from trying to auto-link to the binaries
that Boost.Build generates. You can do this by defining either
BOOST_MATH_NO_LIB or BOOST_ALL_NO_LIB at project level
(so the defines get passed to each compiler invocation).
]
Optionally the sources in `libs/math/src/tr1` have support for using
`libs/math/src/tr1/pch.hpp` as a precompiled header
['if your compiler supports precompiled headers.] Note that normally
this header is a do-nothing include: to activate the header so that
it #includes everything required by all the sources you will need to
define BOOST_BUILD_PCH_ENABLED on the command line, both when building
the pre-compiled header and when building the sources. Boost.Build
will do this automatically when appropriate.
[h4 Building the Examples]
The examples are all located in `libs/math/example`, they can all
be built without reference to any external libraries, either with
Boost.Build using the supplied Jamfile, or from your compiler's
command line. The only requirement is that the Boost headers are
in your compilers #include search path.
[h4 Building the Tests]
The tests are located in `libs/math/test` and are best built
using Boost.Build and the supplied Jamfile. If you plan to
build them separately from your favourite IDE then you will
need to add `libs/math/test` to the list of your compiler's
search paths.
You will also need to build and link to
the Boost.Regex library for many of the tests: this can built
from the command line by following the
[@http://www.boost.org/doc/libs/release/more/getting_started/index.html
getting started guide], using a command such as:
bjam toolset=gcc --with-regex install
or
bjam toolset=msvc --with-regex --build-type=complete stage
depending on whether you are on Linux or Windows.
Many of the tests have optional precompiled header support
using the header `libs/math/test/pch.hpp`.
Note that normally
this header is a do-nothing include: to activate the header so that
it #includes everything required by all the sources you will need to
define BOOST_BUILD_PCH_ENABLED on the command line, both when building
the pre-compiled header and when building the sources. Boost.Build
will do this automatically when appropriate.
[endsect]
[/ building.qbk
Copyright 2006, 2007, 2008, 2010 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/common_overviews.qbk
+231
View File
@@ -0,0 +1,231 @@
[template policy_overview[]
Policies are a powerful fine-grain mechanism that allow you to customise the
behaviour of this library according to your needs. There is more information
available in the [link math_toolkit.pol_tutorial policy tutorial]
and the [link math_toolkit.pol_ref policy reference].
Generally speaking, unless you find that the
[link math_toolkit.pol_tutorial.policy_tut_defaults
default policy behaviour]
when encountering 'bad' argument values does not meet your needs,
you should not need to worry about policies.
Policies are a compile-time mechanism that allow you to change
error-handling or calculation precision either
program wide, or at the call site.
Although the policy mechanism itself is rather complicated,
in practice it is easy to use, and very flexible.
Using policies you can control:
* [link math_toolkit.pol_ref.error_handling_policies How results from 'bad' arguments are handled],
including those that cannot be fully evaluated.
* How [link math_toolkit.pol_ref.internal_promotion accuracy is controlled by internal promotion] to use more precise types.
* What working [link math_toolkit.pol_ref.precision_pol precision] should be used to calculate results.
* What to do when a [link math_toolkit.pol_ref.assert_undefined mathematically undefined function]
is used: Should this raise a run-time or compile-time error?
* Whether [link math_toolkit.pol_ref.discrete_quant_ref discrete functions],
like the binomial, should return real or only integral values, and how they are rounded.
* How many iterations a special function is permitted to perform in
a series evaluation or root finding algorithm before it gives up and raises an
__evaluation_error.
You can control policies:
* Using [link math_toolkit.pol_ref.policy_defaults macros] to
change any default policy: the is the preferred method for installation
wide policies.
* At your chosen [link math_toolkit.pol_ref.namespace_pol
namespace scope] for distributions and/or functions: this is the
preferred method for project, namespace, or translation unit scope
policies.
* In an ad-hoc manner [link math_toolkit.pol_tutorial.ad_hoc_sf_policies
by passing a specific policy to a special function], or to a
[link math_toolkit.pol_tutorial.ad_hoc_dist_policies
statistical distribution].
]
[template performance_overview[]
By and large the performance of this library should be acceptable
for most needs. However, often the library has to make a choice whether to
be accurate or fast and by default it chooses accuracy over speed. If
you would rather have fast rather than fully accurate routines, then
refer to the [link perf performance section] for information and examples on how to
achieve this.
In terms of the algorithms used, this library aims to use the same "best
of breed" algorithms as many other libraries: the principle difference
is that this library is implemented in C++ - taking advantage of all
the abstraction mechanisms that C++ offers - where as most traditional
numeric libraries are implemented in C or FORTRAN. Traditionally
languages such as C or FORTRAN are perceived as easier to optimise
than more complex languages like C++, so in a sense this library
provides a good test of current compiler technology, and the
"abstraction penalty" - if any - of C++ compared to other languages.
The three most important things you can do to ensure the best performance
from this library are:
# Turn on your compilers optimisations: the difference between "release"
and "debug" builds can easily be a [link math_toolkit.getting_best factor of 20].
# Pick your compiler carefully: [link math_toolkit.comp_compilers
performance differences of up to
8 fold] have been found between some Windows compilers for example.
# Disable internal use of `long double`, this will reduce accuracy but
typically yield a 2x speedup on modern x64 hardware/compilers.
The [link perf performance section] contains more
information on the performance
of this library, what you can do to fine tune it, and how this library
compares to some other open source alternatives.
]
[template compilers_overview[]
This section contains some information about how various compilers
work with this library.
It is not comprehensive and updated experiences are always welcome.
Some effort has been made to suppress unhelpful warnings but it is
difficult to achieve this on all systems.
[table Supported/Tested Compilers
[[Platform][Compiler][Has long double support][Notes]]
[[Windows][MSVC 7.1 and later][Yes]
[All tests OK.
We aim to keep our headers warning free at level 4 with
this compiler.]]
[[Windows][Intel 8.1 and later][Yes]
[All tests OK.
We aim to keep our headers warning free at level 4 with
this compiler. However, The tests cases tend to generate a lot of
warnings relating to numeric underflow of the test data: these are
harmless.]]
[[Windows][GNU Mingw32 C++][Yes]
[All tests OK.
We aim to keep our headers warning free with -Wall with this compiler.]]
[[Windows][GNU Cygwin C++][No]
[All tests OK.
We aim to keep our headers warning free with -Wall with this compiler.
Long double support has been disabled because there are no native
long double C std library functions available.]]
[[Windows][Borland C++ 5.8.2 (Developer studio 2006)][No]
[We have only partial compatibility with this compiler:
Long double support has been disabled because the native
long double C standard library functions really only forward to the
double versions. This can result in unpredictable behaviour when
using the long double overloads: for example `sqrtl` applied to a
finite value, can result in an infinite result.
Some functions still fail to compile, there are no known workarounds at present.]]
[[Windows 7/Netbeans 7.2][Clang 3.1][Yes][Spot examples OK. Expect all tests to compile and run OK.]]
[[Linux][GNU C++ 3.4 and later][Yes]
[All tests OK.
We aim to keep our headers warning free with -Wall with this compiler.]]
[[Linux][Clang 3.2][Yes][All tests OK.]]
[[Linux][Intel C++ 10.0 and later][Yes]
[All tests OK.
We aim to keep our headers warning free with -Wall with this compiler.
However, The tests cases tend to generate a lot of
warnings relating to numeric underflow of the test data: these are
harmless.]]
[[Linux][Intel C++ 8.1 and 9.1][No]
[All tests OK.
Long double support has been disabled with these compiler releases
because calling the standard library long double math functions
can result in a segfault. The issue is Linux distribution and
glibc version specific and is Intel bug report #409291. Fully up to date
releases of Intel 9.1 (post version l_cc_c_9.1.046)
shouldn't have this problem. If you need long
double support with this compiler, then comment out the define of
BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS at line 55 of
[@../../../../boost/math/tools/config.hpp boost/math/tools/config.hpp].
We aim to keep our headers warning free with -Wall with this compiler.
However, The tests cases tend to generate a lot of
warnings relating to numeric underflow of the test data: these are
harmless.]]
[[Linux][QLogic PathScale 3.0][Yes]
[Some tests involving conceptual checks fail to build, otherwise
there appear to be no issues.]]
[[Linux][Sun Studio 12][Yes]
[Some tests involving function overload resolution fail to build,
these issues should be rarely encountered in practice.]]
[[Solaris][Sun Studio 12][Yes]
[Some tests involving function overload resolution fail to build,
these issues should be rarely encountered in practice.]]
[[Solaris][GNU C++ 4.x][Yes]
[All tests OK.
We aim to keep our headers warning free with -Wall with this compiler.]]
[[HP Tru64][Compaq C++ 7.1][Yes]
[All tests OK.]]
[[HP-UX Itanium][HP aCC 6.x][Yes]
[All tests OK.
Unfortunately this compiler emits quite a few warnings from libraries
upon which we depend (TR1, Array etc).]]
[[HP-UX PA-RISC][GNU C++ 3.4][No]
[All tests OK.]]
[[Apple Mac OS X, Intel][Darwin/GNU C++ 4.x][Yes][All tests OK.]]
[[Apple Mac OS X, PowerPC][Darwin/GNU C++ 4.x][No]
[All tests OK.
Long double support has been disabled on this platform due to the
rather strange nature of Darwin's 106-bit long double
implementation. It should be possible to make this work if someone
is prepared to offer assistance.]]
[[Apple Mac OS X,][Clang 3.2][Yes][All tests expected to be OK.]]
[[IBM AIX][IBM xlc 5.3][Yes]
[All tests pass except for our fpclassify tests which fail due to a
bug in `std::numeric_limits`, the bug effects the test code, not
fpclassify itself. The IBM compiler group are aware of the problem.]]
]
[table Unsupported Compilers
[[Platform][Compiler]]
[[Windows][Borland C++ 5.9.2 (Borland Developer Studio 2007)]]
[[Windows][MSVC 6 and 7]]
]
If your compiler or platform is not listed above, please try running the
regression tests: cd into boost-root/libs/math/test and do a:
bjam mytoolset
where "mytoolset" is the name of the
[@http://www.boost.org/doc/html/bbv2.html Boost.Build]
toolset used for your
compiler. The chances are that [*many of the accuracy tests will fail
at this stage] - don't panic - the default acceptable error tolerances
are quite tight, especially for long double types with an extended
exponent range (these cause more extreme test cases to be executed
for some functions).
You will need to cast an eye over the output from
the failing tests and make a judgement as to whether
the error rates are acceptable or not.
]
[/ common_overviews.qbk
Copyright 2007, 2012, 2014 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/config_macros.qbk
+61
View File
@@ -0,0 +1,61 @@
[section:config_macros Configuration Macros]
Almost all configuration details are set up automatically by
`<boost\math\tools\config.hpp>`.
In normal use, only policy configuration macros are likely to be used. See __policy_ref.
For reference, information on Boost.Math macros used internally are described briefly below.
[table Boost.Math Macros
[[MACRO][Notes]]
[[`BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS`] [Do not produce or use long double functions: this macro gets set when the platform's
long double or standard library long double support is absent or buggy.]]
[[`BOOST_MATH_USE_FLOAT128`][When set the numeric constants support the `__float128` data type with constants having the `Q` suffix.]]
[[`BOOST_MATH_DISABLE_FLOAT128`][When set the numeric constants do not use the `__float128` data type even if the compiler appears to support it.]]
[[`BOOST_MATH_NO_REAL_CONCEPT_TESTS`] [Do not try to use real concept tests (hardware or software does not support real_concept type).]]
[[`BOOST_MATH_CONTROL_FP`] [Controls FP hardware exceptions - our tests don't support hardware exceptions on MSVC.
May get set to something like: ` _control87(MCW_EM,MCW_EM)`.]]
[[`BOOST_MATH_NO_DEDUCED_FUNCTION_POINTERS`] [This macro is used by our test cases, it is set when an assignment of a function template
to a function pointer requires explicit template arguments to be provided on the function name.]]
[[`BOOST_MATH_USE_C99` ] [Use C99 math functions.]]
[[`BOOST_NO_NATIVE_LONG_DOUBLE_FP_CLASSIFY`] [define if no native (or buggy) `fpclassify(long double)`
even though the other C99 functions are present.]]
[[`BOOST_MATH_SMALL_CONSTANT(x)`] [Helper macro used in our test cases to set underflowing constants set to zero
if this would cause compiler issues.]]
[[`BOOST_MATH_BUGGY_LARGE_FLOAT_CONSTANTS`] [Set if constants too large for a float, will cause "bad" values to be stored in the data,
rather than infinity or a suitably large value.]]
[[`BOOST_MATH_STD_USING`] [Provides `using` statements for many std:: (abs to sqrt) and boost::math (rounds, modf) functions.
This allows these functions to be called unqualified so that if
[@http://en.wikipedia.org/wiki/Argument-dependent_name_lookup argument-dependent Argument Dependent Lookup]
fails to find a suitable overload, then the std:: versions will also be considered.]]
[[`BOOST_FPU_EXCEPTION_GUARD`] [Used at the entrypoint to each special function to reset all FPU exception flags prior
to internal calculations, and then merge the old and new exception flags on function exit. Used as a workaround
on platforms or hardware that behave strangely if any FPU exception flags are set when calling standard library
functions.]]
[[`BOOST_MATH_INSTRUMENT`] [Define to output diagnostics for math functions. This is rather 'global' to Boost.Math and so
coarse-grained that it will probably produce copious output! (Especially because full precision values are output).
Designed primarily for internal use and development.]]
[[`BOOST_MATH_INSTRUMENT_CODE(x)`] [Output selected named variable, for example `BOOST_MATH_INSTRUMENT_CODE("guess = " << guess)`; Used by `BOOST_MATH_INSTRUMENT`]]
[[`BOOST_MATH_INSTRUMENT_VARIABLE(name)`] [Output selected variable, for example `BOOST_MATH_INSTRUMENT_VARIABLE(result);` Used by `BOOST_MATH_INSTRUMENT`]]
[[`BOOST_MATH_INSTRUMENT_FPU`] [Output the state of the FPU's control flags.]]
] [/table]
[table Boost.Math Tuning
[[ Macros for Tuning performance options for specific compilers] [Notes]]
[[`BOOST_MATH_POLY_METHOD`] [See the [link math_toolkit.tuning performance tuning section].]]
[[`BOOST_MATH_RATIONAL_METHOD`] [See the [link math_toolkit.tuning performance tuning section].]]
[[`BOOST_MATH_MAX_POLY_ORDER`] [See the [link math_toolkit.tuning performance tuning section].]]
[[`BOOST_MATH_INT_TABLE_TYPE`] [See the [link math_toolkit.tuning performance tuning section].]]
[[`BOOST_MATH_INT_VALUE_SUFFIX`] [Helper macro for appending the correct suffix to integer constants
which may actually be stored as reals depending on the value of BOOST_MATH_INT_TABLE_TYPE.]]
] [/table]
[endsect] [/section:config_macros Configuration Macros]
[/
Copyright 2010 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/contact_info.qbk
+25
View File
@@ -0,0 +1,25 @@
[section:contact Contact Info and Support]
The main support for this library is via the Boost mailing lists:
* Use the
[@http://www.boost.org/more/mailing_lists.htm#users boost-user list]
for general support questions.
* Use the
[@http://www.boost.org/more/mailing_lists.htm#main boost-developer list]
for discussion about implementation
and or submission of extensions.
You can also find JM at john - at - johnmaddock.co.uk and PAB at
pbristow - at - hetp.u-net.com.
[endsect]
[/
Copyright 2006 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/credits.qbk
+134
View File
@@ -0,0 +1,134 @@
[section:credits Credits and Acknowledgements]
Hubert Holin started the Boost.Math library. The
Quaternions, Octonions, inverse
hyperbolic functions, and the sinus cardinal functions are his.
Daryle Walker wrote the integer gcd and lcm functions.
John Maddock started the special functions, the beta, gamma, erf, polynomial,
and factorial functions are his, as is the "Toolkit" section, and many
of the statistical distributions.
Paul A. Bristow threw down the challenge in
[@http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1668.pdf
A Proposal to add Mathematical Functions for Statistics to the C++
Standard Library] to add the key math functions, especially those essential for
statistics. After JM accepted and solved the difficult problems,
not only numerically, but in full C++ template style, PAB
implemented a few of the statistical distributions. PAB also tirelessly
proof-read everything that JM threw at him (so that all
remaining editorial mistakes are his fault).
Xiaogang Zhang worked on the Bessel functions and elliptic integrals for his
Google Summer of Code project 2006.
Bruno Lalande submitted the "compile time power of a runtime base" code.
Johan R'''&#xE5;'''de wrote the optimised floating-point classification
and manipulation code, and nonfinite facets to permit C99 output of infinities and NaNs.
(nonfinite facets were not added until Boost 1.47 but had been in use with Boost.Spirit).
This library was based on a suggestion from Robert Ramey, author of Boost.Serialization.
Paul A. Bristow expressed the need for better handling of
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2022.pdf
Input & Output of NaN and infinity for the C++ Standard Library]
and suggested following the C99 format.
Antony Polukhin improved lexical cast avoiding stringstream so that
it was no longer necessary to use a globale C99 facet to handle nonfinites.
H'''&#xE5;'''kan Ard'''&#xF6;''',
Boris Gubenko, John Maddock,
Markus Sch'''&#xF6;'''pflin
and Olivier Verdier tested the floating-point library and
Martin Bonner, Peter Dimov and John Maddock provided valuable advice.
Gautam Sewani coded the logistic distribution as part of a Google Summer of Code project 2008.
M. A. (Thijs) van den Berg coded the Laplace distribution.
(Thijs has also threatened to implement some multivariate distributions).
Thomas Mang requested the inverse gamma in chi squared distributions
for Bayesian applications and helped in their implementation,
and provided a nice example of their use.
Professor Nico Temme for advice on the inverse incomplete beta function.
[@http://www.shoup.net Victor Shoup for NTL],
without which it would have much more difficult to
produce high accuracy constants, and especially
the tables of accurate values for testing.
We are grateful to Joel Guzman for helping us stress-test his
[@http://www.boost.org/tools/quickbook/index.htm Boost.Quickbook]
program used to generate the html and pdf versions
of this document, adding several new features en route.
Plots of the functions and distributions were prepared in
[@http://www.w3.org/ W3C] standard
[@http://www.svg.org/ Scalable Vector Graphic (SVG)] format
using a program created by Jacob Voytko during a
[@http://code.google.com/soc/2007/ Google Summer of Code (2007)].
From 2012, the latest versions of all Internet Browsers have support
for rendering SVG (with varying quality). Older versions, especially
(Microsoft Internet Explorer (before IE 9) lack native SVG support
but can be made to work with
[@http://www.adobe.com/svg/viewer/install/ Adobe's free SVG viewer] plugin).
The SVG files can be converted to JPEG or PNG using
[@http://www.inkscape.org/ Inkscape].
We are also indebted to Matthias Schabel for managing the formal Boost-review
of this library, and to all the reviewers - including Guillaume Melquiond,
Arnaldur Gylfason, John Phillips, Stephan Tolksdorf and Jeff Garland
- for their many helpful comments.
Thanks to Mark Coleman and Georgi Boshnakov for spot test values
from __Mathematica, and of course,
to Eric Weisstein for nurturing __Mathworld, an invaluable resource.
The Skew-normal distribution and Owen's t function were written by Benjamin Sobotta.
We thank Thomas Mang for persuading us to allow t distributions
to have infinite degrees of freedom
and contributing to some long discussions about how to improve accuracy
for large non-centrality and/or large degrees of freedom.
Christopher Kormanyos wrote the e_float multiprecision library __TOMS910
which formed the basis for the Boost.Multiprecision library
which now can be used to allow most functions and distributions
to be computed up to a precision of the users' choice,
no longer restricted to built-in floating-point types like double.
(And thanks to Topher Cooper for bring Christopher's e_float to our attention).
Christopher Kormanyos wrote some examples for using __multiprecision,
and added methods for finding zeros of Bessel Functions.
Marco Guazzone provided the hyper-geometric distribution.
Rocco Romeo has found numerous small bugs and generally stress tested the
special functions code to near destruction!
Jeremy William Murphy added polynomial arithmetic tools.
Thomas Luu provided improvements to the quantile of the non-central chi squared distribution quantile.
and his thesis
* [@http://discovery.ucl.ac.uk/1482128/ Fast and accurate parallel computation of quantile functions for random number generation, 2016].
and his paper
Luu, Thomas; (2015), Efficient and Accurate Parallel Inversion of the Gamma Distribution,
SIAM Journal on Scientific Computing , 37 (1) C122 - C141,
[@http://dx.doi.org/10.1137/14095875X].
These also promise to help improve algorithms for computation of quantile of several disitributions,
especially for parallel computation using GPUs.
[endsect] [/section:credits Credits and Acknowledgements]
[/
Copyright 2006, 2007, 2008, 2009, 2010, 2012, 2013, 2015, 2016 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/error_handling.qbk
+403
View File
@@ -0,0 +1,403 @@
[section:error_handling Error Handling]
[def __format [@../../../format/index.html Boost.Format]]
[heading Quick Reference]
Handling of errors by this library is split into two orthogonal parts:
* What kind of error has been raised?
* What should be done when the error is raised?
[warning The default error actions are to throw an exception with an informative error message.
If you do not try to catch the exception, you will not see the message!]
The kinds of errors that can be raised are:
[variablelist
[[Domain Error][Occurs when one or more arguments to a function
are out of range.]]
[[Pole Error][Occurs when the particular arguments cause the function to be
evaluated at a pole with no well defined residual value. For example if
__tgamma is evaluated at exactly -2, the function approaches different limiting
values depending upon whether you approach from just above or just below
-2. Hence the function has no well defined value at this point and a
Pole Error will be raised.]]
[[Overflow Error][Occurs when the result is either infinite, or too large
to represent in the numeric type being returned by the function.]]
[[Underflow Error][Occurs when the result is not zero, but is too small
to be represented by any other value in the type being returned by
the function.]]
[[Denormalisation Error][Occurs when the returned result would be a denormalised value.]]
[[Rounding Error][Occurs when the argument to one of the rounding functions __trunc,
__round and __modf can not be represented as an integer type, is
outside the range of the result type.]]
[[Evaluation Error][Occurs if no method of evaluation is known,
or when an internal error occurred that prevented the
result from being evaluated: this should never occur, but if it does, then
it's likely to be due to an iterative method not converging fast enough.]]
[[Indeterminate Result Error][Occurs when the result of a function is not
defined for the values that were passed to it.]]
]
The action undertaken by each error condition is determined by the current
__Policy in effect. This can be changed program-wide by setting some
configuration macros, or at namespace scope, or at the call site (by
specifying a specific policy in the function call).
The available actions are:
[variablelist
[[throw_on_error][Throws the exception most appropriate to the error condition.]]
[[errno_on_error][Sets ::errno to an appropriate value, and then returns the most
appropriate result]]
[[ignore_error][Ignores the error and simply the returns the most appropriate result.]]
[[user_error][Calls a
[link math_toolkit.pol_tutorial.user_def_err_pol user-supplied error handler].]]
]
The following tables show all the permutations of errors and actions,
with the *default action for each error shown in bold*:
[table Possible Actions for Domain Errors
[[Action] [Behaviour]]
[[throw_on_error][[*Throws `std::domain_error`]]]
[[errno_on_error][Sets `::errno` to `EDOM` and returns `std::numeric_limits<T>::quiet_NaN()`]]
[[ignore_error][Returns `std::numeric_limits<T>::quiet_NaN()`]]
[[user_error][Returns the result of `boost::math::policies::user_domain_error`:
[link math_toolkit.pol_tutorial.user_def_err_pol
this function must be defined by the user].]]
]
[table Possible Actions for Pole Errors
[[Action] [Behaviour]]
[[throw_on_error] [[*Throws `std::domain_error`]]]
[[errno_on_error][Sets `::errno` to `EDOM` and returns `std::numeric_limits<T>::quiet_NaN()`]]
[[ignore_error][Returns `std::numeric_limits<T>::quiet_NaN()`]]
[[user_error][Returns the result of `boost::math::policies::user_pole_error`:
[link math_toolkit.pol_tutorial.user_def_err_pol
this function must be defined by the user].]]
]
[table Possible Actions for Overflow Errors
[[Action] [Behaviour]]
[[throw_on_error][[*Throws `std::overflow_error`]]]
[[errno_on_error][Sets `::errno` to `ERANGE` and returns `std::numeric_limits<T>::infinity()`]]
[[ignore_error][Returns `std::numeric_limits<T>::infinity()`]]
[[user_error][Returns the result of `boost::math::policies::user_overflow_error`:
[link math_toolkit.pol_tutorial.user_def_err_pol
this function must be defined by the user].]]
]
[table Possible Actions for Underflow Errors
[[Action] [Behaviour]]
[[throw_on_error][Throws `std::underflow_error`]]
[[errno_on_error][Sets `::errno` to `ERANGE` and returns 0.]]
[[ignore_error][[*Returns 0]]]
[[user_error][Returns the result of `boost::math::policies::user_underflow_error`:
[link math_toolkit.pol_tutorial.user_def_err_pol
this function must be defined by the user].]]
]
[table Possible Actions for Denorm Errors
[[Action] [Behaviour]]
[[throw_on_error][Throws `std::underflow_error`]]
[[errno_on_error][Sets `::errno` to `ERANGE` and returns the denormalised value.]]
[[ignore_error][[*Returns the denormalised value.]]]
[[user_error][Returns the result of `boost::math::policies::user_denorm_error`:
[link math_toolkit.pol_tutorial.user_def_err_pol
this function must be defined by the user].]]
]
[table Possible Actions for Rounding Errors
[[Action] [Behaviour]]
[[throw_on_error][Throws `boost::math::rounding_error`]]
[[errno_on_error][Sets `::errno` to `ERANGE` and returns the largest representable value of the target integer type
(or the most negative value if the argument to the function was less than zero).]]
[[ignore_error][[*Returns the largest representable value of the target integer type
(or the most negative value if the argument to the function was less than zero).]]]
[[user_error][Returns the result of `boost::math::policies::user_rounding_error`:
[link math_toolkit.pol_tutorial.user_def_err_pol
this function must be defined by the user].]]
]
[table Possible Actions for Internal Evaluation Errors
[[Action] [Behaviour]]
[[throw_on_error][[*Throws `boost::math::evaluation_error`]]]
[[errno_on_error][Sets `::errno` to `EDOM` and returns the closest approximation found.]]
[[ignore_error][Returns the closest approximation found.]]
[[user_error][Returns the result of `boost::math::policies::user_evaluation_error`:
[link math_toolkit.pol_tutorial.user_def_err_pol
this function must be defined by the user].]]
]
[table Possible Actions for Indeterminate Result Errors
[[Action] [Behaviour]]
[[throw_on_error][Throws `std::domain_error`]]
[[errno_on_error][Sets `::errno` to `EDOM` and returns the same value as `ignore_error`.]]
[[ignore_error][[*Returns a default result that depends on the function where the error occurred.]]]
[[user_error][Returns the result of `boost::math::policies::user_indeterminate_result_error`:
[link math_toolkit.pol_tutorial.user_def_err_pol
this function must be defined by the user].]]
]
All these error conditions are in namespace boost::math::policies,
made available, for example, a by namespace declaration
using `namespace boost::math::policies;` or individual using declarations
`using boost::math::policies::overflow_error;`.
[heading Rationale]
The flexibility of the current implementation should be reasonably obvious: the
default behaviours were chosen based on feedback during the formal review of
this library. It was felt that:
* Genuine errors should be flagged with exceptions
rather than following C-compatible behaviour and setting `::errno`.
* Numeric underflow and denormalised results were not considered to be
fatal errors in most cases, so it was felt that these should be ignored.
* If there is more than one error,
only the first detected will be reported in the throw message.
[heading Finding More Information]
There are some pre-processor macro defines that can be used to
[link math_toolkit.pol_ref.policy_defaults
change the policy defaults]. See also the [link policy
policy section].
An example is at the Policy tutorial in
[link math_toolkit.pol_tutorial.changing_policy_defaults
Changing the Policy Defaults].
Full source code of this typical example of passing a 'bad' argument
(negative degrees of freedom) to Student's t distribution
is [link math_toolkit.stat_tut.weg.error_eg in the error handling example].
The various kind of errors are described in more detail below.
[heading:domain_error Domain Errors]
When a special function is passed an argument that is outside the range
of values for which that function is defined, then the function returns
the result of:
boost::math::policies::raise_domain_error<T>(FunctionName, Message, Val, __Policy);
Where
`T` is the floating-point type passed to the function, `FunctionName` is the
name of the function, `Message` is an error message describing the problem,
Val is the value that was out of range, and __Policy is the current policy
in use for the function that was called.
The default policy behaviour of this function is to throw a
std::domain_error C++ exception. But if the __Policy is to ignore
the error, or set global `::errno`, then a NaN will be returned.
This behaviour is chosen to assist compatibility with the behaviour of
['ISO/IEC 9899:1999 Programming languages - C]
and with the
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf Draft Technical Report on C++ Library Extensions, 2005-06-24, section 5.2.1, paragraph 6]:
[:['"Each of the functions declared above shall return a NaN (Not a Number)
if any argument value is a NaN, but it shall not report a domain error.
Otherwise, each of the functions declared above shall report a domain error
for just those argument values for which:]]
[:['"the function description's Returns clause explicitly specifies a domain, and those arguments fall outside the specified domain; or]
['"the corresponding mathematical function value has a non-zero imaginary component; or]
['"the corresponding mathematical function is not mathematically defined.]]
[:['"Note 2: A mathematical function is mathematically defined
for a given set of argument values if it is explicitly defined
for that set of argument values or
if its limiting value exists and does not depend on the direction of approach."]]
Note that in order to support information-rich error messages when throwing
exceptions, `Message` must contain
a __format recognised format specifier: the argument `Val` is inserted into
the error message according to the specifier used.
For example if `Message` contains a "%1%" then it is replaced by the value of
`Val` to the full precision of T, where as "%.3g" would contain the value of
`Val` to 3 digits. See the __format documentation for more details.
[heading:pole_error Evaluation at a pole]
When a special function is passed an argument that is at a pole
without a well defined residual value, then the function returns
the result of:
boost::math::policies::raise_pole_error<T>(FunctionName, Message, Val, __Policy);
Where
`T` is the floating point type passed to the function, `FunctionName` is the
name of the function, `Message` is an error message describing the problem,
`Val` is the value of the argument that is at a pole, and __Policy is the
current policy in use for the function that was called.
The default behaviour of this function is to throw a std::domain_error exception.
But __error_policy can be used to change this, for example to `ignore_error`
and return NaN.
Note that in order to support information-rich error messages when throwing
exceptions, `Message` must contain
a __format recognised format specifier: the argument `val` is inserted into
the error message according to the specifier used.
For example if `Message` contains a "%1%" then it is replaced by the value of
`val` to the full precision of T, where as "%.3g" would contain the value of
`val` to 3 digits. See the __format documentation for more details.
[heading:overflow_error Numeric Overflow]
When the result of a special function is too large to fit in the argument
floating-point type, then the function returns the result of:
boost::math::policies::raise_overflow_error<T>(FunctionName, Message, __Policy);
Where
`T` is the floating-point type passed to the function, `FunctionName` is the
name of the function, `Message` is an error message describing the problem,
and __Policy is the current policy
in use for the function that was called.
The default policy for this function is that `std::overflow_error`
C++ exception is thrown. But if, for example, an `ignore_error` policy
is used, then returns `std::numeric_limits<T>::infinity()`.
In this situation if the type `T` doesn't support infinities,
the maximum value for the type is returned.
[heading:underflow_error Numeric Underflow]
If the result of a special function is known to be non-zero, but the
calculated result underflows to zero, then the function returns the result of:
boost::math::policies::raise_underflow_error<T>(FunctionName, Message, __Policy);
Where
`T` is the floating point type passed to the function, `FunctionName` is the
name of the function, `Message` is an error message describing the problem,
and __Policy is the current policy
in use for the called function.
The default version of this function returns zero.
But with another policy, like `throw_on_error`,
throws an `std::underflow_error` C++ exception.
[heading:denorm_error Denormalisation Errors]
If the result of a special function is a denormalised value /z/ then the function
returns the result of:
boost::math::policies::raise_denorm_error<T>(z, FunctionName, Message, __Policy);
Where
`T` is the floating point type passed to the function, `FunctionName` is the
name of the function, `Message` is an error message describing the problem,
and __Policy is the current policy
in use for the called function.
The default version of this function returns /z/.
But with another policy, like `throw_on_error`
throws an `std::underflow_error` C++ exception.
[heading:evaluation_error Evaluation Errors]
When a special function calculates a result that is known to be erroneous,
or where the result is incalculable then it calls:
boost::math::policies::raise_evaluation_error<T>(FunctionName, Message, Val, __Policy);
Where
`T` is the floating point type passed to the function, `FunctionName` is the
name of the function, `Message` is an error message describing the problem,
`Val` is the erroneous value,
and __Policy is the current policy
in use for the called function.
The default behaviour of this function is to throw a `boost::math::evaluation_error`.
Note that in order to support information rich error messages when throwing
exceptions, `Message` must contain
a __format recognised format specifier: the argument `val` is inserted into
the error message according to the specifier used.
For example if `Message` contains a "%1%" then it is replaced by the value of
`val` to the full precision of T, where as "%.3g" would contain the value of
`val` to 3 digits. See the __format documentation for more details.
[heading:indeterminate_result_error Indeterminate Result Errors]
When the result of a special function is indeterminate for the value that was
passed to it, then the function returns the result of:
boost::math::policies::raise_overflow_error<T>(FunctionName, Message, Val, Default, __Policy);
Where
`T` is the floating-point type passed to the function, `FunctionName` is the
name of the function, `Message` is an error message describing the problem,
Val is the value for which the result is indeterminate, Default is an
alternative default result that must be returned for `ignore_error` and
`errno_on_erro` policies, and __Policy is the current policy in use for the
function that was called.
The default policy for this function is `ignore_error`: note that this error
type is reserved for situations where the result is mathematically
undefined or indeterminate, but there is none the less a convention for what
the result should be: for example the C99 standard specifies that the result
of 0[super 0] is 1, even though the result is actually mathematically indeterminate.
[heading:rounding_error Rounding Errors]
When one of the rounding functions __round, __trunc or __modf is
called with an argument that has no integer representation, or
is too large to be represented in the result type then the
value returned is the result of a call to:
boost::math::policies::raise_rounding_error<T>(FunctionName, Message, Val, __Policy);
Where
`T` is the floating point type passed to the function, `FunctionName` is the
name of the function, `Message` is an error message describing the problem,
`Val` is the erroneous argument,
and __Policy is the current policy in use for the called function.
The default behaviour of this function is to throw a `boost::math::rounding_error`.
Note that in order to support information rich error messages when throwing
exceptions, `Message` must contain
a __format recognised format specifier: the argument `val` is inserted into
the error message according to the specifier used.
For example if `Message` contains a "%1%" then it is replaced by the value of
`val` to the full precision of T, where as "%.3g" would contain the value of
`val` to 3 digits. See the __format documentation for more details.
[heading:checked_narrowing_cast Errors from typecasts]
Many special functions evaluate their results at a higher precision
than their arguments in order to ensure full machine precision in
the result: for example, a function passed a float argument may evaluate
its result using double precision internally. Many of the errors listed
above may therefore occur not during evaluation, but when converting
the result to the narrower result type. The function:
template <class T, class __Policy, class U>
T checked_narrowing_cast(U const& val, const char* function);
Is used to perform these conversions, and will call the error handlers
listed above on [link math_toolkit.error_handling.overflow_error overflow],
[link math_toolkit.error_handling.underflow_error underflow] or [link math_toolkit.error_handling.denorm_error denormalisation].
[endsect][/section:error_handling Error Handling]
[/
Copyright 2006 - 2012 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/faq.qbk
+104
View File
@@ -0,0 +1,104 @@
[section:main_faq Frequently Asked Questions FAQ]
# ['I'm a FORTRAN/NAG/SPSS/SAS/Cephes/MathCad/R user
and I don't see where the functions like dnorm(mean, sd) are in Boost.Math?] [br]
Nearly all are provided, and many more like mean, skewness, quantiles, complements ...
but Boost.Math makes full use of C++, and it looks a bit different.
But do not panic! See section on construction and the many examples.
Briefly, the distribution is constructed with the parameters (like location and scale)
(things after the | in representation like P(X=k|n, p) or ; in a common represention of pdf f(x; [mu][sigma][super 2]).
Functions like pdf, cdf are called with the name of that distribution and the random variate often called x or k.
For example, `normal my_norm(0, 1); pdf(my_norm, 2.0);` [br]
#I'm a user of [@http://support.sas.com/rnd/app/da/new/probabilityfunctions.html New SAS Functions for Computing Probabilities]. [br]
You will find the interface more familar, but to be able to select a distribution (perhaps using a string)
see the Extras/Future Directions section,
and /boost/libs/math/dot_net_example/boost_math.cpp for an example that is used to create a C# (C sharp) utility
(that you might also find useful):
see [@http://sourceforge.net/projects/distexplorer/ Statistical Distribution Explorer].[br]
# ['I'm allegic to reading manuals and prefer to learn from examples.][br]
Fear not - you are not alone! Many examples are available for functions and distributions.
Some are referenced directly from the text. Others can be found at \boost_latest_release\libs\math\example.
If you are a Visual Studio user, you should be able to create projects from each of these,
making sure that the Boost library is in the include directories list.
# ['How do I make sure that the Boost library is in the Visual Studio include directories list?][br]
You can add an include path, for example, your Boost place /boost-latest_release,
for example `X:/boost_1_45_0/` if you have a separate partition X for Boost releases.
Or you can use an environment variable BOOST_ROOT set to your Boost place, and include that.
Visual Studio before 2010 provided Tools, Options, VC++ Directories to control directories:
Visual Studio 2010 instead provides property sheets to assist.
You may find it convenient to create a new one adding \boost-latest_release;
to the existing include items in $(IncludePath).
# ['I'm a FORTRAN/NAG/SPSS/SAS/Cephes/MathCad/R user and
I don't see where the properties like mean, median, mode, variance, skewness of distributions are in Boost.Math?][br]
They are all available (if defined for the parameters with which you constructed the distribution) via __usual_accessors.
# ['I am a C programmer. Can I user Boost.Math with C?][br]
Yes you can, including all the special functions, and TR1 functions like isnan.
They appear as C functions, by being declared as "extern C".
# ['I am a C# (Basic? F# FORTRAN? Other CLI?) programmer. Can I use Boost.Math with C#? (or ...)?] [br]
Yes you can, including all the special functions, and TR1 functions like isnan.
But you [*must build the Boost.Math as a dynamic library (.dll) and compile with the /CLI option].
See the boost/math/dot_net_example folder which contains an example that
builds a simple statistical distribution app with a GUI.
See [@http://sourceforge.net/projects/distexplorer/ Statistical Distribution Explorer] [br]
# ['What these "policies" things for?] [br]
Policies are a powerful (if necessarily complex) fine-grain mechanism that
allow you to customise the behaviour of the Boost.Math library according to your precise needs.
See __policy_section. But if, very probably, the default behaviour suits you, you don't need to know more.
# ['I am a C user and expect to see global C-style`::errno` set for overflow/errors etc?] [br]
You can achieve what you want - see __error_policy and __user_error_handling and many examples.
# ['I am a C user and expect to silently return a max value for overflow?] [br]
You (and C++ users too) can return whatever you want on overflow
- see __overflow_error and __error_policy and several examples.
# ['I don't want any error message for overflow etc?] [br]
You can control exactly what happens for all the abnormal conditions, including the values returned.
See __domain_error, __overflow_error __error_policy __user_error_handling etc and examples.
# ['My environment doesn't allow and/or I don't want exceptions. Can I still user Boost.Math?] [br]
Yes but you must customise the error handling: see __user_error_handling and __changing_policy_defaults .
# ['The docs are several hundreds of pages long! Can I read the docs off-line or on paper?] [br]
Yes - you can download the Boost current release of most documentation
as a zip of pdfs (including Boost.Math) from Sourceforge, for example
[@https://sourceforge.net/projects/boost/files/boost-docs/1.45.0/boost_pdf_1_45_0.tar.gz/download].
And you can print any pages you need (or even print all pages - but be warned that there are several hundred!).
Both html and pdf versions are highly hyperlinked.
The entire Boost.Math pdf can be searched with Adobe Reader, Edit, Find ...
This can often find what you seek, a partial substitute for a full index.
# ['I want a compact version for an embedded application. Can I use float precision?] [br]
Yes - by selecting RealType template parameter as float:
for example normal_distribution<float> your_normal(mean, sd);
(But double may still be used internally, so space saving may be less that you hope for).
You can also change the promotion policy, but accuracy might be much reduced.
# ['I seem to get somewhat different results compared to other programs. Why?]
We hope Boost.Math to be more accurate: our priority is accuracy (over speed).
See the section on accuracy. But for evaluations that require iterations
there are parameters which can change the required accuracy (see __policy_section).
You might be able to squeeze a little more (or less) accuracy at the cost of runtime.
# ['Will my program run more slowly compared to other math functions and statistical libraries?]
Probably, thought not always, and not by too much: our priority is accuracy.
For most functions, making sure you have the latest compiler version with all optimisations switched on is the key to speed.
For evaluations that require iteration, you may be able to gain a little more speed at the expense of accuracy.
See detailed suggestions and results on __performance.
# ['How do I handle infinity and NaNs portably?] [br]
See __fp_facets for Facets for Floating-Point Infinities and NaNs.
# ['Where are the pre-built libraries?] [br]
Good news - you probably don't need any! - just `#include <boost/`['math/distribution_you_want>].
But in the unlikely event that you do, see __building.
# ['I don't see the function or distribution that I want.] [br]
You could try an email to ask the authors - but no promises!
# ['I need more decimal digits for values/computations.] [br]
You can use Boost.Math with __multiprecision: typically
__cpp_dec_float is a useful user-defined type to provide a fixed number of decimal digits, usually 50 or 100.
# Why can't I write something really simple like `cpp_int one(1); cpp_dec_float_50 two(2); one * two;`
Because `cpp_int` might be bigger than `cpp_dec_float can hold`, so you must make an [*explicit] conversion.
See [@http://svn.boost.org/svn/boost/trunk/libs/multiprecision/doc/html/boost_multiprecision/intro.html mixed multiprecision arithmetic]
and [@http://svn.boost.org/svn/boost/trunk/libs/multiprecision/doc/html/boost_multiprecision/tut/conversions.html conversion].
[endsect] [/section:faq Frequently Asked Questions]
[/
Copyright 2010, 2012 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/issues.qbk
+153
View File
@@ -0,0 +1,153 @@
[section:issues Known Issues, and TODO List]
Predominantly this is a TODO list, or a list of possible
future enhancements. Items labled "High Priority" effect
the proper functioning of the component, and should be fixed
as soon as possible. Items labled "Medium Priority" are
desirable enhancements, often pertaining to the performance
of the component, but do not effect it's accuracy or functionality.
Items labled "Low Priority" should probably be investigated at
some point. Such classifications are obviously highly subjective.
If you don't see a component listed here, then we don't have any known
issues with it.
[h4 Derivatives of Bessel functions (and their zeros)]
Potentially, there could be native support
for `cyl_bessel_j_prime()` and `cyl_neumann_prime()`.
One could also imagine supporting the zeros
thereof, but they might be slower to calculate
since root bracketing might be needed instead
of Newton iteration (for the lack of 2nd derivatives).
Since Boost.Math's Bessel functions are so excellent,
the quick way to `cyl_bessel_j_prime()` and
`cyl_neumann_prime()` would be via relationship with
`cyl_bessel_j()` and `cyl_neumann()`.
[h4 tgamma]
* Can the __lanczos be optimized any further? (low priority)
[h4 Incomplete Beta]
* Investigate Didonato and Morris' asymptotic expansion for large a and b
(medium priority).
[h4 Inverse Gamma]
* Investigate whether we can skip iteration altogether if the first approximation
is good enough (Medium Priority).
[h4 Polynomials]
* The Legendre and Laguerre Polynomials have surprisingly different error
rates on different platforms, considering they are evaluated with only
basic arithmetic operations. Maybe this is telling us something, or maybe not
(Low Priority).
[h4 Elliptic Integrals]
* [para Carlson's algorithms (mainly R[sub J]) are somewhat prone to
internal overflow/underflow when the arguments are very large or small.
The homogeneity relations:]
[para R[sub F](ka, kb, kc) = k[super -1/2] R[sub F](a, b, c)]
[para and]
[para R[sub J](ka, kb, kc, kr) = k[super -3/2] R[sub J](a, b, c, r)]
[para could be used to sidestep trouble here: provided the problem domains
can be accurately identified. (Medium Priority).]
* There are a several other integrals: Bulirsch's ['el] functions that could
be implemented using Carlson's integrals (Low Priority).
* The integrals K(k) and E(k) could be implemented using rational
approximations (both for efficiency and accuracy),
assuming we can find them. (Medium Priority).
[h4 Owen's T Function]
There is a problem area at arbitrary precision when ['a] is very close to 1. However, note that
the value for ['T(h, 1)] is well known and easy to compute, and if we replaced the
['a[super k]] terms in series T1, T2 or T4 by ['(a[super k] - 1)] then we would have the
difference between ['T(h, a)] and ['T(h, 1)]. Unfortunately this doesn't improve the
convergence of those series in that area. It certainly looks as though a new series in terms
of ['(1-a)[super k]] is both possible and desirable in this area, but it remains elusive at present.
[h4 Jocobi elliptic functions]
These are useful in engineering applications - we have had a request to add these.
[h4 Statistical distributions]
* Student's t Perhaps switch to normal distribution
as a better approximation for very large degrees of freedom?
[h4 Feature Requests]
We have a request for the Lambert W function, see [@https://svn.boost.org/trac/boost/ticket/11027 #11027].
The following table lists distributions that are found in other packages
but which are not yet present here, the more frequently the distribution
is found, the higher the priority for implementing it:
[table
[[Distribution][R][Mathematica 6][NIST][Regress+][Matlab]]
[/3 votes:]
[[Geometric][X][X][-][-][X]]
[/2 votes:]
[[Multinomial][X][-][-][-][X]]
[[Tukey Lambda][X][-][X][-][-]]
[[Half Normal / Folded Normal][-][X][-][X][-]]
[[Chi][-][X][-][X][-]]
[[Gumbel][-][X][-][X][-]]
[[Discrete Uniform][-][X][-][-][X]]
[[Log Series][-][X][-][X][-]]
[[Nakagami (generalised Chi)][-][-][-][X][X]]
[/1 vote:]
[[Log Logistic][-][-][-][-][X]]
[[Tukey (Studentized range)][X][-][-][-][-]]
[[Wilcoxon rank sum][X][-][-][-][-]]
[[Wincoxon signed rank][X][-][-][-][-]]
[[Non-central Beta][X][-][-][-][-]]
[[Maxwell][-][X][-][-][-]]
[[Beta-Binomial][-][X][-][-][-]]
[[Beta-negative Binomial][-][X][-][-][-]]
[[Zipf][-][X][-][-][-]]
[[Birnbaum-Saunders / Fatigue Life][-][-][X][-][-]]
[[Double Exponential][-][-][X][-][-]]
[[Power Normal][-][-][X][-][-]]
[[Power Lognormal][-][-][X][-][-]]
[[Cosine][-][-][-][X][-]]
[[Double Gamma][-][-][-][X][-]]
[[Double Weibul][-][-][-][X][-]]
[[Hyperbolic Secant][-][-][-][X][-]]
[[Semicircular][-][-][-][X][-]]
[[Bradford][-][-][-][X][-]]
[[Birr / Fisk][-][-][-][X][-]]
[[Reciprocal][-][-][-][X][-]]
[/0 votes but useful anyway?]
[[Kolmogorov Distribution][-][-][-][-][-]]
]
Also asked for more than once:
* Add support for interpolated distributions, possibly combine with numeric
integration and differentiation.
* Add support for bivariate and multivariate distributions: most especially the normal.
* Add support for the log of the cdf and pdf:
this is mainly a performance optimisation since we can avoid
some special function calls for some distributions
by returning the log of the result.
[endsect] [/section:issues Known Issues, and Todo List]
[/
Copyright 2006, 2010 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/overview.qbk
+93
View File
@@ -0,0 +1,93 @@
[section:main_intro About the Math Toolkit]
This library is divided into three interconnected parts:
[h4 Statistical Distributions]
Provides a reasonably comprehensive set of
[link dist statistical distributions],
upon which higher level statistical tests can be built.
The initial focus is on the central
[@http://en.wikipedia.org/wiki/Univariate univariate ]
[@http://mathworld.wolfram.com/StatisticalDistribution.html distributions].
Both [@http://mathworld.wolfram.com/ContinuousDistribution.html continuous]
(like [link math_toolkit.dist_ref.dists.normal_dist normal]
& [link math_toolkit.dist_ref.dists.f_dist Fisher])
and [@http://mathworld.wolfram.com/DiscreteDistribution.html discrete]
(like [link math_toolkit.dist_ref.dists.binomial_dist binomial]
& [link math_toolkit.dist_ref.dists.poisson_dist Poisson])
distributions are provided.
A [link math_toolkit.stat_tut comprehensive tutorial is provided],
along with a series of
[link math_toolkit.stat_tut.weg worked examples] illustrating
how the library is used to conduct statistical tests.
[h4 Mathematical Special Functions]
Provides a small number of high quality
[link special special functions],
initially these were concentrated on functions used in statistical applications
along with those in the [tr1].
The function families currently implemented are the gamma, beta & erf functions
along with the incomplete gamma and beta functions (four variants
of each) and all the possible inverses of these, plus digamma,
various factorial functions,
Bessel functions, elliptic integrals, sinus cardinals (along with their
hyperbolic variants), inverse hyperbolic functions, Legrendre/Laguerre/Hermite
polynomials and various
special power and logarithmic functions.
All the implementations
are fully generic and support the use of arbitrary "real-number" types,
including __multiprecision,
although they are optimised for use with types with known-about
[@http://en.wikipedia.org/wiki/Significand significand (or mantissa)]
sizes: typically `float`, `double` or `long double`.
[h4 Implementation Toolkit]
The section [link math_toolkit.internals_overview Internal tools]
provides many of the tools required to implement
mathematical special functions: hopefully the presence of
these will encourage other authors to contribute more special
function implementations in the future.
Some tools are now considered well-tried and their signatures stable and unlikely to change.
There is a fairly comprehensive set of root finding both
__root_finding_without_derivatives
and __root_finding_with_derivatives with derivative support,
and function minimization using __brent_minima.
Other [link math_toolkit.internals_overview Internal tools]
are currently still considered experimental: they are "exposed implementation details"
whose interfaces and\/or implementations may change without notice.
There are helpers for the
[link math_toolkit.internals.series_evaluation evaluation of infinite series],
[link math_toolkit.internals.cf continued
fractions] and [link math_toolkit.roots.rational
rational approximations].
A [link math_toolkit.internals.minimax Remez algorithm implementation]
allows for the locating of minimax rational
approximations.
There are also (experimental) classes for the
[link math_toolkit.roots.polynomials manipulation of polynomials], for
[link math_toolkit.internals.error_test
testing a special function against tabulated test data], and for
the [link math_toolkit.internals.test_data
rapid generation of test data] and/or data for output to an
external graphing application.
[endsect] [/section:intro Introduction]
[/
Copyright 2006, 2012, 2015 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/result_type_calc.qbk
+85
View File
@@ -0,0 +1,85 @@
[section:result_type Calculation of the Type of the Result]
The functions in this library are all overloaded to accept
mixed floating point (or mixed integer and floating point type)
arguments. So for example:
foo(1.0, 2.0);
foo(1.0f, 2);
foo(1.0, 2L);
etc, are all valid calls, as long as "foo" is a function taking two
floating-point arguments. But that leaves the question:
[blurb ['"Given a special function with N arguments of
types T1, T2, T3 ... TN, then what type is the result?"]]
[*If all the arguments are of the same (floating point) type then the
result is the same type as the arguments.]
Otherwise, the type of the result
is computed using the following logic:
# Any arguments that are not template arguments are disregarded from
further analysis.
# For each type in the argument list, if that type is an integer type
then it is treated as if it were of type double for the purposes of
further analysis.
# If any of the arguments is a user-defined class type, then the result type
is the first such class type that is constructible from all of the other
argument types.
# If any of the arguments is of type `long double`, then the result is of type
`long double`.
# If any of the arguments is of type `double`, then the result is of type
`double`.
# Otherwise the result is of type `float`.
For example:
cyl_bessel(2, 3.0);
Returns a `double` result, as does:
cyl_bessel(2, 3.0f);
as in this case the integer first argument is treated as a `double` and takes
precedence over the `float` second argument. To get a `float` result we would need
all the arguments to be of type float:
cyl_bessel_j(2.0f, 3.0f);
When one or more of the arguments is not a template argument then it
doesn't effect the return type at all, for example:
sph_bessel(2, 3.0f);
returns a `float`, since the first argument is not a template argument and
so doesn't effect the result: without this rule functions that take
explicitly integer arguments could never return `float`.
And for user-defined types, all of the following return an `NTL::RR` result:
cyl_bessel_j(0, NTL::RR(2));
cyl_bessel_j(NTL::RR(2), 3);
cyl_bessel_j(NTL::quad_float(2), NTL::RR(3));
In the last case, `quad_float` is convertible to `RR`, but not vice-versa, so
the result will be an `NTL::RR`. Note that this assumes that you are using
a [link math_toolkit.high_precision.use_ntl patched NTL library].
These rules are chosen to be compatible with the behaviour of
['ISO/IEC 9899:1999 Programming languages - C]
and with the
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf Draft Technical Report on C++ Library Extensions, 2005-06-24, section 5.2.1, paragraph 5].
[endsect]
[/
Copyright 2006, 2012 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/roadmap.qbk
+418
View File
@@ -0,0 +1,418 @@
[template history[]
Currently open bug reports can be viewed
[@https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=reopened&component=math&col=id&col=summary&col=status&col=type&col=milestone&col=component&order=priority here].
All bug reports including closed ones can be viewed
[@https://svn.boost.org/trac/boost/query?status=assigned&status=closed&status=new&status=reopened&component=math&col=id&col=summary&col=status&col=type&col=milestone&col=component&order=priority here].
[h4 Math-2.5.1 (Boost-1.63)]
Patches:
* Fixed evaluation of zero polynomial in polynomial.hpp, see [@https://svn.boost.org/trac/boost/ticket/12532 12532].
* Fixed missing header include in boost/math/tools/tuple.hpp, see [@https://svn.boost.org/trac/boost/ticket/12537 12537].
[h4 Math-2.5.0 (Boost-1.62)]
New Features:
* Enabled all the special function code to work correctly with types whose precision can change at runtime: for example type `mpfr_float` from Boost.Multiprecision.
Patches:
* Fix tgamma_delta_ratio for cases where the delta is small compared to the base.
* Fix misc GCC-4.4 test failures.
[h4 Math-2.4.0 (Boost-1.61)]
New Features:
* Polynomial arithmetic added to tools.
[h4 Math-2.3.0 (Boost-1.60)]
New Features:
* Promote the root finding and function minimization code to first class citizens - these are now officially supported as part of the library.
* Allow the library to be used and tested with compiler exception handling support turned off. To better facilitate this
the default error handling policies have been changed to ['errno_on_error] but only when the compiler has no exception handling support.
Patches:
* Fix behaviour of the non-central chi-squared distribution when the non-centrality parameter is zero to match the chi-squared,
see [@https://svn.boost.org/trac/boost/ticket/11557 11557].
* Fix comments in code for the hypergeometric to match what it actually does, also fixes the parameter access functions to return
the correct values. See [@https://svn.boost.org/trac/boost/ticket/11556 11556].
* Stopped using hidden visiblity library build with the Oracle compiler as it leads to unresolved externals from the C++ standard library.
See [@https://svn.boost.org/trac/boost/ticket/11547 11547].
* Fix unintended use of __declspec when building with Oracle C++. See [@https://svn.boost.org/trac/boost/ticket/11546 11546].
* Fix corner case bug in root bracketing code, see [@https://svn.boost.org/trac/boost/ticket/11532 11532].
* Add some missing typecasts in arguments to std::max in Bernoulli code. See [@https://svn.boost.org/trac/boost/ticket/11453 11453].
* Fix mistaken assumptions about the possible values for FLT_EVAL_METHOD. See [@https://svn.boost.org/trac/boost/ticket/11429 11429].
* Completely revamped performance testing and error-rate measuring code so we can more easily document how well (or not!) we're doing.
This information will hopefully get more frequently updated in future as it's more or less automatically generated - see the /reporting/
sub-directory for more information.
* Fix some corner cases in the beta, incomplete beta, and incomplete beta derivative. With thanks to Rocco Romeo.
* Reorganized the Bessel functions internally to improve the performance of Jn and Yn.
* Fixed skewness formula for triangular distribution, see [@https://svn.boost.org/trac/boost/ticket/11768 #11768].
* Fixed some examples so they compile on Unix platforms which have an ::exception struct declared, see [@https://svn.boost.org/trac/boost/ticket/11827 #11827].
* Correct mistake in triangular distribution skewness formula [@https://svn.boost.org/trac/boost/ticket/11768 11768],
reported by Juan Leni.
[h4 Math-2.2.1]
Patch release for Boost-1.58:
* Minor [@https://github.com/boostorg/math/pull/13#issuecomment-98905579 patch for Haiku support.]
* Fix the decimal digit count for 128-bit floating point types.
* Fix a few documentation typos.
[h4 Math-2.2.0 (boost-1.58.0)]
* Added two new special functions - __trigamma and __polygamma.
* Fixed namespace scope constants so they are constexpr on conforming compilers, see https://svn.boost.org/trac/boost/ticket/10901.
* Fixed various cases of spurious under/overflow in the incomplete beta and gamma functions, plus the elliptic integrals,
with thanks to Rocco Romeo.
* Fix 3-arg __legendre_p and __legendre_q functions to not call the policy based overload if the final argument
is not actually a policy.
* Cleaned up some dead code in the incomplete beta function, see [@https://svn.boost.org/trac/boost/ticket/10985 #10985].
* Fixed extreme-value pdf for large valued inputs, see [@https://svn.boost.org/trac/boost/ticket/10938 #10938].
* Large update to the Elliptic integral code to use Carlson's latest algorithms - these should be more stable, more accurate
and slightly faster than before. Also added support for Carlson's RG integral.
* Added __ellint_d, __jacobi_zeta and __heuman_lambda elliptic integrals.
* Switched documentation to use SVG rather than PNG graphs and equations - browsers seem to have finally caught up!
[h4 Math-2.1.0 (boost-1.57.0)]
* Added __hyperexponential_distrib.
* Fix some spurious overflows in the incomplete gamma functions (with thanks to Rocco Romeo).
* Fix bug in derivative of incomplete beta when a = b = 0.5 - this also effects several non-central distributions,
see [@https://svn.boost.org/trac/boost/ticket/10480 10480].
* Fixed some corner cases in __round.
* Don't support 80-bit floats in cstdfloat.hpp if standard library support is broken.
[h4 Math-2.0.0 (Boost-1.56.0)]
* [*Breaking change]: moved a number of non-core headers that are predominantly used for internal
maintenance into `libs/math/include_private`. The headers effected are `boost/math/tools/test_data.hpp`,
`boost/math/tools/remez.hpp`, `boost/math/constants/generate.hpp`, `boost/math/tools/solve.hpp`,
`boost/math/tools/test.hpp`.
You can continue to use these headers by adding `libs/math/include_private` to your compiler's include path.
* [*Breaking change]: A number of distributions and special functions were returning the maximum finite value
rather than raising an __overflow_error, this has now been fixed, which means these functions now behave as
documented. However, since the default behavior on raising an __overflow_error is to throw a `std::overflow_error`
exception, applications which have come to reply rely on these functions not throwing may experience exceptions
where they did not before. The special functions involved are __gamma_p_inva, __gamma_q_inva,
__ibeta_inva, __ibetac_inva, __ibeta_invb, __ibetac_invb, __gamma_p_inv, __gamma_q_inv. The distributions
involved are __pareto_distrib, __beta_distrib, __geometric_distrib, __negative_binomial_distrib,
__binomial_distrib, __chi_squared_distrib, __gamma_distrib, __inverse_chi_squared_distrib,
__inverse_gamma_distrib. See [@https://svn.boost.org/trac/boost/ticket/10111 #10111].
* Fix __round and __trunc functions so they can be used with integer arguments, see [@https://svn.boost.org/trac/boost/ticket/10066 #10066].
* Fix Halley iteration to handle zero derivative (with non-zero second derivative), see [@https://svn.boost.org/trac/boost/ticket/10046 #10046].
[h4 Math-1.9.1]
* Fix Geometric distribution use of Policies, see [@https://svn.boost.org/trac/boost/ticket/9833 #9833].
* Fix corner cases in the negative binomial distribution, see [@https://svn.boost.org/trac/boost/ticket/9834 #9834].
* Fix compilation failures on Mac OS.
[h4 Math-1.9.0]
* Changed version number to new Boost.Math specific version now that we're in the modular Boost world.
* Added __bernoulli_numbers, changed arbitrary precision __tgamma/__lgamma to use Sterling's approximation (from Nikhar Agrawal).
* Added first derivatives of the Bessel functions: __cyl_bessel_j_prime, __cyl_neumann_prime, __cyl_bessel_i_prime, __cyl_bessel_k_prime, __sph_bessel_prime and __sph_neumann_prime (from Anton Bikineev).
* Fixed buggy Student's t example code, along with docs for testing sample means for equivalence.
* Documented `max_iter` parameter in root finding code better, see [@https://svn.boost.org/trac/boost/ticket/9225 #9225].
* Add option to explicitly enable/disable use of __float128 in constants code, see [@https://svn.boost.org/trac/boost/ticket/9240 #9240].
* Cleaned up handling of negative values in Bessel I0 and I1 code (removed dead code), see [@https://svn.boost.org/trac/boost/ticket/9512 #9512].
* Fixed handling of very small values passed to __tgamma and __lgamma so they don't generate spurious overflows (thanks to Rocco Romeo).
* [@https://svn.boost.org/trac/boost/ticket/9672 #9672 PDF and CDF of a Laplace distribution throwing domain_error]
Random variate can now be infinite.
* Fixed several corner cases in __rising_factorial, __falling_factorial and __tgamma_delta_ratio with thanks to Rocco Romeo.
* Fixed several corner cases in __rising_factorial, __falling_factorial and __tgamma_delta_ratio (thanks to Rocco Romeo).
* Removed constant `pow23_four_minus_pi ` whose value did not match the name (and was unused by Boost.Math), see
[@https://svn.boost.org/trac/boost/ticket/9712 #9712].
[h4 Boost-1.55]
* Suppress numerous warnings (mostly from GCC-4.8 and MSVC) [@https://svn.boost.org/trac/boost/ticket/8384 #8384], [@https://svn.boost.org/trac/boost/ticket/8855 #8855],
[@https://svn.boost.org/trac/boost/ticket/9107 #9107], [@https://svn.boost.org/trac/boost/ticket/9109 #9109]..
* Fixed PGI compilation issue [@https://svn.boost.org/trac/boost/ticket/8333 #8333].
* Fixed PGI constant value initialization issue that caused erf to generate incorrect results [@https://svn.boost.org/trac/boost/ticket/8621 #8621].
* Prevent macro expansion of some C99 macros that are also C++ functions [@https://svn.boost.org/trac/boost/ticket/8732 #8732] and [@https://svn.boost.org/trac/boost/ticket/8733 #8733]..
* Fixed Student's T distribution to behave correctly with huge degrees of freedom (larger than the largest representable integer) [@https://svn.boost.org/trac/boost/ticket/8837 #8837].
* Make some core functions usable with `long double` even when the platform has no standard library `long double` support [@https://svn.boost.org/trac/boost/ticket/8940 #8940].
* Fix error handling of distributions to catch invalid scale and location parameters when the random variable is infinite [@https://svn.boost.org/trac/boost/ticket/9042 #9042] and [@https://svn.boost.org/trac/boost/ticket/9126 #9126].
* Add workaround for broken <tuple> in Intel C++ 14 [@https://svn.boost.org/trac/boost/ticket/9087 #9087].
* Improve consistency of argument reduction in the elliptic integrals [@https://svn.boost.org/trac/boost/ticket/9104 #9104].
* Fix bug in inverse incomplete beta that results in cancellation errors when the beta function is really an arcsine or Student's T distribution.
* Fix issue in Bessel I and K function continued fractions that causes spurious over/underflow.
* Add improvement to non-central chi squared distribution quantile due to Thomas Luu,
[@http://discovery.ucl.ac.uk/1482128/ Fast and accurate parallel computation of quantile functions for random number generation, Doctorial Thesis 2016].
[@http://discovery.ucl.ac.uk/1463470/ Efficient and Accurate Parallel Inversion of the Gamma Distribution, Thomas Luu]
[h4 Boost-1.54]
* Major reorganization to incorporate other Boost.Math like Integer Utilities Integer Utilities (Greatest Common Divisor and Least Common Multiple), quaternions and octonions.
Making new chapter headings.
* Added many references to Boost.Multiprecision and `cpp_dec_float_50` as an example of a User-defined Type (UDT).
* Added Clang to list of supported compilers.
* Fixed constants to use a thread-safe cache of computed values when used at arbitrary precision.
* Added finding zeros of Bessel functions `cyl_bessel_j_zero`, `cyl_neumann_zero`, `airy_ai_zero` and `airy_bi_zero`(by Christopher Kormanyos).
* More accuracy improvements to the Bessel J and Y functions from Rocco Romeo.
* Fixed nasty cyclic dependency bug that caused some headers to not compile [@https://svn.boost.org/trac/boost/ticket/7999 #7999].
* Fixed bug in __tgamma that caused spurious overflow for arguments between 142.5 and 143.
* Fixed bug in raise_rounding_error that caused it to return an incorrect result when throwing an exception is turned off [@https://svn.boost.org/trac/boost/ticket/7905 #7905].
* Added minimal __float128 support.
* Fixed bug in edge-cases of poisson quantile [@https://svn.boost.org/trac/boost/ticket/8308 #8308].
* Adjusted heuristics used in Halley iteration to cope with inverting the incomplete beta in tricky regions
where the derivative is flatlining. Example is computing the quantile of the Fisher F distribution for probabilities
smaller than machine epsilon. See ticket [@https://svn.boost.org/trac/boost/ticket/8314 #8314].
[h4 Boost-1.53]
* Fixed issues [@https://svn.boost.org/trac/boost/ticket/7325 #7325], [@https://svn.boost.org/trac/boost/ticket/7415 #7415]
and [@https://svn.boost.org/trac/boost/ticket/7416 #7416], [@https://svn.boost.org/trac/boost/ticket/7183 #7183],
[@https://svn.boost.org/trac/boost/ticket/7649 #7649], [@https://svn.boost.org/trac/boost/ticket/7694 #7694],
[@https://svn.boost.org/trac/boost/ticket/4445 #4445], [@https://svn.boost.org/trac/boost/ticket/7492 #7492],
[@https://svn.boost.org/trac/boost/ticket/7891 #7891], [@https://svn.boost.org/trac/boost/ticket/7429 #7429].
* Fixed mistake in calculating pooled standard deviation in two-sample students t example
[@https://svn.boost.org/trac/boost/ticket/7402 #7402].
* Improve complex acos/asin/atan, see [@https://svn.boost.org/trac/boost/ticket/7290 #7290],
[@https://svn.boost.org/trac/boost/ticket/7291 #7291].
* Improve accuracy in some corner cases of __cyl_bessel_j and __gamma_p/__gamma_q thanks to suggestions from Rocco Romeo.
* Improve accuracy of Bessel J and Y for integer orders thanks to suggestions from Rocco Romeo.
[h4 Boost-1.52]
* Corrected moments for small degrees of freedom [@https://svn.boost.org/trac/boost/ticket/7177 #7177] (reported by Thomas Mang).
* Added [link math_toolkit.airy Airy functions] and [link math_toolkit.jacobi Jacobi Elliptic functions].
* Corrected failure to detect bad parameters in many distributions
[@https://svn.boost.org/trac/boost/ticket/6934 #6934] (reported by Florian Schoppmann)
by adding a function check_out_of_range to test many possible bad parameters.
This test revealed several distributions where the checks for bad parameters were ineffective,
and these have been rectified.
* Fixed issue in Hankel functions that causes incorrect values to be returned for ['x < 0] and [nu] odd, see [@https://svn.boost.org/trac/boost/ticket/7135 #7135].
* Fixed issues [@https://svn.boost.org/trac/boost/ticket/6517 #6517], [@https://svn.boost.org/trac/boost/ticket/6362 #6362],
[@https://svn.boost.org/trac/boost/ticket/7053 #7053], [@https://svn.boost.org/trac/boost/ticket/2693 #2693],
[@https://svn.boost.org/trac/boost/ticket/6937 #6937], [@https://svn.boost.org/trac/boost/ticket/7099 #7099].
* Permitted infinite degrees of freedom [@https://svn.boost.org/trac/boost/ticket/7259 #7259]
implemented using the normal distribution (requested by Thomas Mang).
* Much enhanced accuracy for large degrees of freedom [nu] and/or large non-centrality [delta]
by switching to use the Students t distribution
(or Normal distribution for infinite degrees of freedom)
centered at delta,
when [delta] / (4 * [nu]) < epsilon for the floating-point type in use.
[@https://svn.boost.org/trac/boost/ticket/7259 #7259].
It was found that the incomplete beta was suffering from serious cancellation errors
when degrees of freedom was very large. (That has now been fixed in our code,
but any code based on Didonato and Morris's original papers
(probably every implementation out there actually) will have the same issue).
[h4 Boost-1.51]
See Boost-1.52 - some items were added but not listed in time for the release.
[h4 Boost-1.50]
* Promoted math constants to be 1st class citizens,
including convenient access to the most widely used
built-in float, double, long double via three namespaces.
* Added the Owen's T function and Skew Normal distribution written by Benjamin Sobotta: see __owens_t and skew_normal_distrib.
* Added Hankel functions __cyl_hankel_1, __cyl_hankel_2, __sph_hankel_1 and __sph_hankel_2.
* Corrected issue [@https://svn.boost.org/trac/boost/ticket/6627 #6627 nonfinite_num_put formatting of 0.0 is incorrect]
based on a patch submitted by K R Walker.
* Changed constant initialization mechanism so that it is thread safe even for user-defined types, also
so that user defined types get the full precision of the constant, even when `long double` does not.
So for example 128-bit rational approximations will work with UDT's and do the right thing, even though
`long double` may be only 64 or 80 bits.
* Fixed issue in `bessel_jy` which causes Y[sub 8.5](4[pi]) to yield a NaN.
[h4 Boost-1.49]
* Deprecated wrongly named `twothirds` math constant in favour of `two_thirds` (with underscore separator).
(issue [@https://svn.boost.org/trac/boost/ticket/6199 #6199]).
* Refactored test data and some special function code to improve support for arbitary precision and/or expression-template-enabled types.
* Added new faster zeta function evaluation method.
Fixed issues:
* Corrected CDF complement for Laplace distribution (issue [@https://svn.boost.org/trac/boost/ticket/6151 #6151]).
* Corrected branch cuts on the complex inverse trig functions, to handle signed zeros (issue [@https://svn.boost.org/trac/boost/ticket/6171 #6171]).
* Fixed bug in `bessel_yn` which caused incorrect overflow errors to be raised for negative ['n] (issue [@https://svn.boost.org/trac/boost/ticket/6367 #6367]).
* Also fixed minor/cosmetic/configuration issues [@https://svn.boost.org/trac/boost/ticket/6120 #6120], [@https://svn.boost.org/trac/boost/ticket/6191 #6191],
[@https://svn.boost.org/trac/boost/ticket/5982 #5982], [@https://svn.boost.org/trac/boost/ticket/6130 #6130],
[@https://svn.boost.org/trac/boost/ticket/6234 #6234], [@https://svn.boost.org/trac/boost/ticket/6307 #6307],
[@https://svn.boost.org/trac/boost/ticket/6192 #6192].
[h4 Boost-1.48]
* Added new series evaluation methods to the cyclic Bessel I, J, K and Y functions.
Also taken great care to avoid spurious over and underflow of these functions.
Fixes issue [@https://svn.boost.org/trac/boost/ticket/5560 #5560]
* Added an example of using Inverse Chi-Squared distribution for Bayesian statistics,
provided by Thomas Mang.
* Added tests to use improved version of lexical_cast which handles C99 nonfinites without using globale facets.
* Corrected wrong out-of-bound uniform distribution CDF complement values [@https://svn.boost.org/trac/boost/ticket/5733 #5733].
* Enabled long double support on OpenBSD (issue [@https://svn.boost.org/trac/boost/ticket/6014 #6014]).
* Changed nextafter and related functions to behave in the same way as other implementations - so that nextafter(+INF, 0)
is a finite value (issue [@https://svn.boost.org/trac/boost/ticket/5823 #5832]).
* Changed tuple include configuration to fix issue when using in conjunction with Boost.Tr1 (issue [@https://svn.boost.org/trac/boost/ticket/5934 #5934]).
* Changed class eps_tolerance to behave correctly when both ends of the range are zero (issue [@https://svn.boost.org/trac/boost/ticket/6001 #6001]).
* Fixed missing include guards on prime.hpp (issue [@https://svn.boost.org/trac/boost/ticket/5927 #5927]).
* Removed unused/undocumented constants from constants.hpp (issue [@https://svn.boost.org/trac/boost/ticket/5982 #5982]).
* Fixed missing std:: prefix in nonfinite_num_facets.hpp (issue [@https://svn.boost.org/trac/boost/ticket/5914 #5914]).
* Minor patches for Cray compiler compatibility.
[h4 Boost-1.47]
* Added changesign function to sign.hpp to facilitate addition of nonfinite facets.
* Addition of nonfinite facets from Johan Rade, with tests,
examples of use for C99 format infinity and NaN, and documentation.
* Added tests and documentation of changesign from Johan Rade.
[h4 Boost-1.46.1]
* Fixed issues [@https://svn.boost.org/trac/boost/ticket/5095 #5095], [@https://svn.boost.org/trac/boost/ticket/5095 #5113].
[h4 Boost-1.46.0]
* Added Wald, Inverse Gaussian and geometric distributions.
* Added information about configuration macros.
* Added support for mpreal as a real-numbered type.
[h4 Boost-1.45.0]
* Added warnings about potential ambiguity with std random library in distribution and function names.
* Added inverse gamma distribution and inverse chi_square and scaled inverse chi_square.
* Editorial revision of documentation, and added FAQ.
[h4 Boost-1.44.0]
* Fixed incorrect range and support for Rayleigh distribution.
* Fixed numerical error in the quantile of the Student's T distribution: the function was
returning garbage values for non-integer degrees of freedom between 2 and 3.
[h4 Boost-1.41.0]
* Significantly improved performance for the incomplete gamma function and its inverse.
[h4 Boost-1.40.0]
* Added support for MPFR as a bignum type.
* Added some full specializations of the policy classes to reduce compile times.
* Added logistic and hypergeometric distributions, from Gautam Sewani's Google Summer of Code project.
* Added Laplace distribution submitted by Thijs van den Berg.
* Updated performance test code to include new distributions, and improved the performance of the non-central distributions.
* Added SSE2 optimised __lanczos code, from Gautam Sewani's Google Summer of Code project.
* Fixed bug in cyl_bessel_i that used an incorrect approximation for [nu] = 0.5, also effects the non-central
Chi Square Distribution when [nu] = 3, see bug report [@https://svn.boost.org/trac/boost/ticket/2877 #2877].
* Fixed minor bugs [@https://svn.boost.org/trac/boost/ticket/2873 #2873].
[h4 Boost-1.38.0]
* Added Johan R'''&#xE5;'''de's optimised floating point classification routines.
* Fixed code so that it compiles in GCC's -pedantic mode (bug report
[@https://svn.boost.org/trac/boost/ticket/1451 #1451]).
[h4 Boost-1.37.0]
* Improved accuracy and testing of the inverse hypergeometric functions.
[h4 Boost-1.36.0]
* Added Noncentral Chi Squared Distribution.
* Added Noncentral Beta Distribution.
* Added Noncentral F Distribution.
* Added Noncentral T Distribution.
* Added Exponential Integral Functions.
* Added Zeta Function.
* Added Rounding and Truncation functions.
* Added Compile time powers of runtime bases.
* Added SSE2 optimizations for Lanczos evaluation.
[h4 Boost-1.35.0: Post Review First Official Release]
* Added Policy based framework that allows fine grained control
over function behaviour.
* [*Breaking change:] Changed default behaviour for domain, pole and overflow errors
to throw an exception (based on review feedback), this
behaviour can be customised using __Policy's.
* [*Breaking change:] Changed exception thrown when an internal evaluation error
occurs to boost::math::evaluation_error.
* [*Breaking change:] Changed discrete quantiles to return an integer result:
this is anything up to 20 times faster than finding the true root, this
behaviour can be customised using __Policy's.
* Polynomial/rational function evaluation is now customisable and hopefully
faster than before.
* Added performance test program.
[h4 Milestone 4: Second Review Candidate (1st March 2007)]
* Moved Xiaogang Zhang's Bessel Functions code into the library,
and brought them into line with the rest of the code.
* Added C# "Distribution Explorer" demo application.
[h4 Milestone 3: First Review Candidate (31st Dec 2006)]
* Implemented the main probability distribution and density functions.
* Implemented digamma.
* Added more factorial functions.
* Implemented the Hermite, Legendre and Laguerre polynomials plus the
spherical harmonic functions from TR1.
* Moved Xiaogang Zhang's elliptic integral code into the library,
and brought them into line with the rest of the code.
* Moved Hubert Holin's existing Boost.Math special functions
into this library and brought them into line with the rest of the code.
[h4 Milestone 2: Released September 10th 2006]
* Implement preview release of the statistical distributions.
* Added statistical distributions tutorial.
* Implemented root finding algorithms.
* Implemented the inverses of the incomplete gamma and beta functions.
* Rewrite erf/erfc as rational approximations (valid to 128-bit precision).
* Integrated the statistical results generated from
the test data with Boost.Test: uses a database of expected
results, indexed by test, floating point type, platform, and compiler.
* Improved lgamma near 1 and 2 (rational approximations).
* Improved erf/erfc inverses (rational approximations).
* Implemented Rational function generation (the Remez method).
[h4 Milestone 1: Released March 31st 2006]
* Implement gamma/beta/erf functions along with their incomplete counterparts.
* Generate high quality test data, against which future improvements can be judged.
* Provide tools for the evaluation of infinite series, continued fractions, and
rational functions.
* Provide tools for testing against tabulated test data, and collecting statistics
on error rates.
* Provide sufficient docs for people to be able to find their way around the library.
SVN Revisions:
Sandbox and trunk last synchonised at revision: .
]
[/
Copyright 2006 - 2013 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/structure.qbk
+193
View File
@@ -0,0 +1,193 @@
[section:navigation Navigation]
[indexterm1 navigation]
Boost.Math documentation is provided in both HTML and PDF formats.
* [*Tutorials] are listed in the ['Table of Contents] and
include many examples that should help you get started quickly.
* [*Source code] of the many ['Examples] will often be your quickest starting point.
* [*Index] (general) includes all entries.
* [*Specific Indexes] list only functions, class signatures, macros and typedefs.
[h5 Using the Indexes]
The main index will usually help,
especially if you know a word describing what it does,
without needing to know the exact name chosen for the function.
[tip When using the index, keep in mind that clicking on an index term
only takes you to the [*section] containing the index entry.
This section may be several pages long,
so you may need to use the [*find] facility of your browser or PDF reader
to get to the index term itself.]
[tip A PDF reader usually allows a [*global] find; this can be really useful
if the term you expect to be indexed is not the one chosen by the authors.
You might find searching the PDF version and viewing the HTML version
will locate an elusive item.]
[endsect] [/section:navigation Navigation]
[section:conventions Document Conventions]
[indexterm1 conventions]
This documentation aims to use of the following naming and formatting conventions.
* C++ Code is in `fixed width font` and is syntax-highlighted in color, for example `double`.
* Other code is in block [^teletype fixed-width font].
* Replaceable text that [*you] will need to supply is in [~italics].
* If a name refers to a free function, it is specified like this:
`free_function()`; that is, it is in [~code font] and its name is followed by `()`
to indicate that it is a free function.
* If a name refers to a class template, it is specified like this:
`class_template<>`; that is, it is in code font and its name is followed by `<>`
to indicate that it is a class template.
* If a name refers to a function-like macro, it is specified like this: `MACRO()`;
that is, it is uppercase in code font and its name is followed by `()` to
indicate that it is a function-like macro. Object-like macros appear without the
trailing `()`.
* Names that refer to ['concepts] in the generic programming sense
(like template parameter names) are specified in CamelCase.
[endsect] [/section:conventions Document Conventions]
[section:hints Other Hints and tips]
* If you have a feature request,
or if it appears that the implementation is in error,
please search first in the [@https://svn.boost.org/trac/boost/ Boost Trac].
* [@https://svn.boost.org/trac/boost/ Trac] entries may indicate that
updates or corrections that solve your problem are in
[@http://svn.boost.org/svn/boost/trunk Boost-trunk]
where changes are being assembled and tested ready for the next release.
You may, at your own risk, download new versions from there.
* If you do not understand why things work the way they do, see the ['rationale] section.
* If you do not find your idea/feature/complaint,
please reach the author preferably through the Boost
development list, or email the author(s) direct.
[h5 Admonishments]
[note In addition, notes such as this one specify non-essential information that
provides additional background or rationale.]
[tip These blocks contain information that you may find helpful while coding.]
[important These contain information that is imperative to understanding a concept.
Failure to follow suggestions in these blocks will probably result in undesired behavior.
Read all of these you find.]
[warning Failure to heed this will lead to incorrect,
and very likely undesired, results.]
[endsect] [/section:hints Other Hints and tips]
[section:directories Directory and File Structure]
[h4 boost\/math]
[variablelist
[[\/concepts\/]
[Prototype defining the *essential* features of a RealType
class (see real_concept.hpp). Most applications will use `double`
as the RealType (and short `typedef` names of distributions are
reserved for this type where possible), a few will use `float` or
`long double`, but it is also possible to use higher precision types
like __NTL_RR, __GMP, __MPFR
that conform to the requirements specified by real_concept.]]
[[\/constants\/]
[Templated definition of some highly accurate math
constants (in constants.hpp).]]
[[\/distributions\/]
[Distributions used in mathematics and, especially, statistics:
Gaussian, Students-t, Fisher, Binomial etc]]
[[\/policies\/]
[Policy framework, for handling user requested behaviour modifications.]]
[[\/special_functions\/]
[Math functions generally regarded as 'special', like beta,
cbrt, erf, gamma, lgamma, tgamma ... (Some of these are specified in
C++, and C99\/TR1, and perhaps TR2).]]
[[\/tools\/]
[Tools used by functions, like evaluating polynomials, continued fractions,
root finding, precision and limits, and by tests. Some will
find application outside this package.]]
]
[h4 boost\/libs]
[variablelist
[[\/doc\/]
[Documentation source files in Quickbook format processed into
html and pdf formats.]]
[[\/examples\/]
[Examples and demos of using math functions and distributions.]]
[[\/performance\/]
[Performance testing and tuning program.]]
[[\/test\/]
[Test files, in many .cpp files, most using Boost.Test
(some with test data as .ipp files, usually generated using NTL RR
type with ample precision for the type, often for precisions
suitable for up to 256-bit significand real types).]]
[[\/tools\/]
[Programs used to generate test data. Also changes to the
[@http://shoup.net/ntl/ NTL] released package to provide a few additional
(and vital) extra features.]]
]
[endsect] [/section:directories Directory and File Structure]
[section:namespaces Namespaces]
All math functions and distributions are in `namespace boost::math`
So, for example, the Students-t distribution template in `namespace boost::math` is
template <class RealType> class students_t_distribution
and can be instantiated with the help of the reserved name `students_t`(for `RealType double`)
typedef students_t_distribution<double> students_t;
student_t mydist(10);
[warning Some distribution names are also used in std random library,
so to avoid the risk of ambiguity it is better to make explicit using declarations,
for example: `using boost::math::students_t_distribution`]
Functions not intended for use by applications are in `boost::math::detail`.
Functions that may have more general use, like `digits`
(significand), `max_value`, `min_value` and `epsilon` are in
`boost::math::tools`.
__Policy and configuration information is in namespace `boost::math::policies`.
[tip Many code snippets assume implicit namespace(s),
for example, `std::` or `boost::math`.]
[endsect] [/section:namespaces Namespaces]
[/ structure.qbk
Copyright 2006, 2010, 2012 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/thread_safety.qbk
+15
View File
@@ -0,0 +1,15 @@
[section:threads Thread Safety]
The library is fully thread safe and re-entrant for all functions
regards of the data type they are instantiated on. Thread safety
limitations relating to user defined types present in previous
releases (prior to 1.50.0) have been removed.
[endsect] [/section:threads Thread Safety]
[/
Copyright 2006 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]
libs/math/doc/overview/tr1.qbk
+398
View File
@@ -0,0 +1,398 @@
[template tr1_overview[]
Many of the special functions included in this library are also a part
of the either the [C99] or the [tr1]. Therefore this library
includes a thin wrapper header `boost/math/tr1.hpp` that provides
compatibility with these two standards.
There are various pros and cons to using the library in this way:
Pros:
* The header to include is lightweight (i.e. fast to compile).
* The functions have extern "C" linkage,
and so are usable from other languages (not just C and C++).
* C99 and C++ TR1 Standard compatibility.
Cons:
* You will need to compile and link to the external Boost.Math libraries.
* Limited to support for the types, `float`, `double` and `long double`.
* Error handling is handled via setting ::errno and returning NaN's and
infinities: this may be less flexible than an C++ exception based approach.
[note The separate libraries are required *only* if you choose to use
boost/math/tr1.hpp rather than some other Boost.Math header, the rest
of Boost.Math remains header-only.]
The separate libraries required in order to use tr1.hpp can be compiled
using bjam from within the libs/math/build directory, or from the Boost
root directory using the usual Boost-wide install procedure.
Alternatively the source files are located in libs/math/src and each have
the same name as the function they implement. The various libraries are
named as follows:
[table
[[Name][Type][Functions]]
[[boost_math_c99f-<suffix>][float][C99 Functions]]
[[boost_math_c99-<suffix>][double][C99 Functions]]
[[boost_math_c99l-<suffix>][long double][C99 Functions]]
[[boost_math_tr1f-<suffix>][float][TR1 Functions]]
[[boost_math_tr1-<suffix>][double][TR1 Functions]]
[[boost_math_tr1l-<suffix>][long double][TR1 Functions]]
]
Where `<suffix>` encodes the compiler and build options used to
build the libraries: for example "libboost_math_tr1-vc80-mt-gd.lib"
would be the statically linked TR1 library to use with Visual C++ 8.0,
in multithreading debug mode, with the DLL VC++ runtime, where as
"boost_math_tr1-vc80-mt.lib" would be import library for the TR1 DLL
to be used with Visual C++ 8.0 with the release multithreaded DLL
VC++ runtime.
Refer to the getting started guide for a
[@http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming
full explanation of the `<suffix>` meanings].
[note
Visual C++ users will typically have the correct library variant to link
against selected for them by boost/math/tr1.hpp based on your compiler
settings.
Users will need to define BOOST_MATH_TR1_DYN_LINK when building
their code if they want to link against the DLL versions of these libraries
rather than the static versions.
Users can disable auto-linking by defining BOOST_MATH_TR1_NO_LIB when
building: this is typically only used when linking against a customised
build of the libraries.]
[note Linux and Unix users will generally only have one variant of
these libraries installed, and can generally just link against
-lboost_math_tr1 etc.]
[h4 Usage Recomendations]
This library now presents the user with a choice:
* To include the header only versions of the functions and have
an easier time linking, but a longer compile time.
* To include the TR1 headers and link against an external library.
Which option you choose depends largely on how you prefer to work
and how your system is set up.
For example a casual user who just needs the acosh function, would
probably be better off including `<boost/math/special_functions/acosh.hpp>`
and using `boost::math::acosh(x)` in their code.
However, for large scale
software development where compile times are significant, and where the
Boost libraries are already built and installed on the system, then
including `<boost/math/tr1.hpp>` and using `boost::math::tr1::acosh(x)`
will speed up compile times, reduce object files sizes (since there are
no templates being instantiated any more), and also speed up debugging
runtimes - since the externally compiled libraries can be
compiler optimised, rather than built using full settings - the difference
in performance between
[link math_toolkit.getting_best
release and debug builds can be as much as 20 times],
so for complex applications this can be a big win.
[h4 Supported C99 Functions]
See also the [link math_toolkit.c99
quick reference guide for these functions].
namespace boost{ namespace math{ namespace tr1{ extern "C"{
typedef unspecified float_t;
typedef unspecified double_t;
double acosh(double x);
float acoshf(float x);
long double acoshl(long double x);
double asinh(double x);
float asinhf(float x);
long double asinhl(long double x);
double atanh(double x);
float atanhf(float x);
long double atanhl(long double x);
double cbrt(double x);
float cbrtf(float x);
long double cbrtl(long double x);
double copysign(double x, double y);
float copysignf(float x, float y);
long double copysignl(long double x, long double y);
double erf(double x);
float erff(float x);
long double erfl(long double x);
double erfc(double x);
float erfcf(float x);
long double erfcl(long double x);
double expm1(double x);
float expm1f(float x);
long double expm1l(long double x);
double fmax(double x, double y);
float fmaxf(float x, float y);
long double fmaxl(long double x, long double y);
double fmin(double x, double y);
float fminf(float x, float y);
long double fminl(long double x, long double y);
double hypot(double x, double y);
float hypotf(float x, float y);
long double hypotl(long double x, long double y);
double lgamma(double x);
float lgammaf(float x);
long double lgammal(long double x);
long long llround(double x);
long long llroundf(float x);
long long llroundl(long double x);
double log1p(double x);
float log1pf(float x);
long double log1pl(long double x);
long lround(double x);
long lroundf(float x);
long lroundl(long double x);
double nextafter(double x, double y);
float nextafterf(float x, float y);
long double nextafterl(long double x, long double y);
double nexttoward(double x, long double y);
float nexttowardf(float x, long double y);
long double nexttowardl(long double x, long double y);
double round(double x);
float roundf(float x);
long double roundl(long double x);
double tgamma(double x);
float tgammaf(float x);
long double tgammal(long double x);
double trunc(double x);
float truncf(float x);
long double truncl(long double x);
}}}} // namespaces
[h4 Supported TR1 Functions]
See also the [link math_toolkit.main_tr1
quick reference guide for these functions].
namespace boost{ namespace math{ namespace tr1{ extern "C"{
// [5.2.1.1] associated Laguerre polynomials:
double assoc_laguerre(unsigned n, unsigned m, double x);
float assoc_laguerref(unsigned n, unsigned m, float x);
long double assoc_laguerrel(unsigned n, unsigned m, long double x);
// [5.2.1.2] associated Legendre functions:
double assoc_legendre(unsigned l, unsigned m, double x);
float assoc_legendref(unsigned l, unsigned m, float x);
long double assoc_legendrel(unsigned l, unsigned m, long double x);
// [5.2.1.3] beta function:
double beta(double x, double y);
float betaf(float x, float y);
long double betal(long double x, long double y);
// [5.2.1.4] (complete) elliptic integral of the first kind:
double comp_ellint_1(double k);
float comp_ellint_1f(float k);
long double comp_ellint_1l(long double k);
// [5.2.1.5] (complete) elliptic integral of the second kind:
double comp_ellint_2(double k);
float comp_ellint_2f(float k);
long double comp_ellint_2l(long double k);
// [5.2.1.6] (complete) elliptic integral of the third kind:
double comp_ellint_3(double k, double nu);
float comp_ellint_3f(float k, float nu);
long double comp_ellint_3l(long double k, long double nu);
// [5.2.1.8] regular modified cylindrical Bessel functions:
double cyl_bessel_i(double nu, double x);
float cyl_bessel_if(float nu, float x);
long double cyl_bessel_il(long double nu, long double x);
// [5.2.1.9] cylindrical Bessel functions (of the first kind):
double cyl_bessel_j(double nu, double x);
float cyl_bessel_jf(float nu, float x);
long double cyl_bessel_jl(long double nu, long double x);
// [5.2.1.10] irregular modified cylindrical Bessel functions:
double cyl_bessel_k(double nu, double x);
float cyl_bessel_kf(float nu, float x);
long double cyl_bessel_kl(long double nu, long double x);
// [5.2.1.11] cylindrical Neumann functions;
// cylindrical Bessel functions (of the second kind):
double cyl_neumann(double nu, double x);
float cyl_neumannf(float nu, float x);
long double cyl_neumannl(long double nu, long double x);
// [5.2.1.12] (incomplete) elliptic integral of the first kind:
double ellint_1(double k, double phi);
float ellint_1f(float k, float phi);
long double ellint_1l(long double k, long double phi);
// [5.2.1.13] (incomplete) elliptic integral of the second kind:
double ellint_2(double k, double phi);
float ellint_2f(float k, float phi);
long double ellint_2l(long double k, long double phi);
// [5.2.1.14] (incomplete) elliptic integral of the third kind:
double ellint_3(double k, double nu, double phi);
float ellint_3f(float k, float nu, float phi);
long double ellint_3l(long double k, long double nu, long double phi);
// [5.2.1.15] exponential integral:
double expint(double x);
float expintf(float x);
long double expintl(long double x);
// [5.2.1.16] Hermite polynomials:
double hermite(unsigned n, double x);
float hermitef(unsigned n, float x);
long double hermitel(unsigned n, long double x);
// [5.2.1.18] Laguerre polynomials:
double laguerre(unsigned n, double x);
float laguerref(unsigned n, float x);
long double laguerrel(unsigned n, long double x);
// [5.2.1.19] Legendre polynomials:
double legendre(unsigned l, double x);
float legendref(unsigned l, float x);
long double legendrel(unsigned l, long double x);
// [5.2.1.20] Riemann zeta function:
double riemann_zeta(double);
float riemann_zetaf(float);
long double riemann_zetal(long double);
// [5.2.1.21] spherical Bessel functions (of the first kind):
double sph_bessel(unsigned n, double x);
float sph_besself(unsigned n, float x);
long double sph_bessell(unsigned n, long double x);
// [5.2.1.22] spherical associated Legendre functions:
double sph_legendre(unsigned l, unsigned m, double theta);
float sph_legendref(unsigned l, unsigned m, float theta);
long double sph_legendrel(unsigned l, unsigned m, long double theta);
// [5.2.1.23] spherical Neumann functions;
// spherical Bessel functions (of the second kind):
double sph_neumann(unsigned n, double x);
float sph_neumannf(unsigned n, float x);
long double sph_neumannl(unsigned n, long double x);
}}}} // namespaces
In addition sufficient additional overloads of the `double` versions of the
above functions are provided, so that calling the function with any mixture
of `float`, `double`, `long double`, or /integer/ arguments is supported, with the
return type determined by the __arg_promotion_rules.
[h4 Currently Unsupported C99 Functions]
double exp2(double x);
float exp2f(float x);
long double exp2l(long double x);
double fdim(double x, double y);
float fdimf(float x, float y);
long double fdiml(long double x, long double y);
double fma(double x, double y, double z);
float fmaf(float x, float y, float z);
long double fmal(long double x, long double y, long double z);
int ilogb(double x);
int ilogbf(float x);
int ilogbl(long double x);
long long llrint(double x);
long long llrintf(float x);
long long llrintl(long double x);
double log2(double x);
float log2f(float x);
long double log2l(long double x);
double logb(double x);
float logbf(float x);
long double logbl(long double x);
long lrint(double x);
long lrintf(float x);
long lrintl(long double x);
double nan(const char *str);
float nanf(const char *str);
long double nanl(const char *str);
double nearbyint(double x);
float nearbyintf(float x);
long double nearbyintl(long double x);
double remainder(double x, double y);
float remainderf(float x, float y);
long double remainderl(long double x, long double y);
double remquo(double x, double y, int *pquo);
float remquof(float x, float y, int *pquo);
long double remquol(long double x, long double y, int *pquo);
double rint(double x);
float rintf(float x);
long double rintl(long double x);
double scalbln(double x, long ex);
float scalblnf(float x, long ex);
long double scalblnl(long double x, long ex);
double scalbn(double x, int ex);
float scalbnf(float x, int ex);
long double scalbnl(long double x, int ex);
[h4 Currently Unsupported TR1 Functions]
// [5.2.1.7] confluent hypergeometric functions:
double conf_hyperg(double a, double c, double x);
float conf_hypergf(float a, float c, float x);
long double conf_hypergl(long double a, long double c, long double x);
// [5.2.1.17] hypergeometric functions:
double hyperg(double a, double b, double c, double x);
float hypergf(float a, float b, float c, float x);
long double hypergl(long double a, long double b, long double c,
long double x);
]
[/
Copyright 2008 John Maddock and Paul A. Bristow.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt).
]