1[section:high_precision Using Boost.Math with High-Precision Floating-Point Libraries] 2 3The special functions, distributions, constants and tools in this library 4can be used with a number of high-precision libraries, including: 5 6* __multiprecision 7* __e_float 8* __NTL 9* __GMP 10* __MPFR 11* __float128 12 13The last four have some license restrictions; 14only __multiprecision when using the `cpp_float` backend 15can provide an unrestricted [@http://www.boost.org/LICENSE_1_0.txt Boost] license. 16 17At present, the price of a free license is slightly lower speed. 18 19Of course, the main cost of higher precision is very much decreased 20(usually at least hundred-fold) computation speed, and big increases in memory use. 21 22Some libraries offer true 23[@http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic arbitrary precision arithmetic] 24where the precision is limited only by avilable memory and compute time, but most are used 25at some arbitrarily-fixed precision, say 100 decimal digits. 26 27__multiprecision can operate in both ways, but the most popular choice is likely to be about a hundred 28decimal digits, though examples of computing tens of thousands of digits have been demonstrated. 29 30[section:why_high_precision Why use a high-precision library rather than built-in floating-point types?] 31 32For nearly all applications, the built-in floating-point types, `double` 33(and `long double` if this offers higher precision than `double`) 34offer enough precision, typically a dozen decimal digits. 35 36Some reasons why one would want to use a higher precision: 37 38* A much more precise result (many more digits) is just a requirement. 39* The range of the computed value exceeds the range of the type: factorials are the textbook example. 40* Using double is (or may be) too inaccurate. 41* Using long double (or may be) is too inaccurate. 42* Using an extended precision type implemented in software as 43[@http://en.wikipedia.org/wiki/Double-double_(arithmetic)#Double-double_arithmetic double-double] 44([@http://en.wikipedia.org/wiki/Darwin_(operating_system) Darwin]) is sometimes unpredictably inaccurate. 45* Loss of precision or inaccuracy caused by extreme arguments or cancellation error. 46* An accuracy as good as possible for a chosen built-in floating-point type is required. 47* As a reference value, for example, to determine the inaccuracy 48of a value computed with a built-in floating point type, 49(perhaps even using some quick'n'dirty algorithm). 50The accuracy of many functions and distributions in Boost.Math has been measured in this way 51from tables of very high precision (up to 1000 decimal digits). 52 53Many functions and distributions have differences from exact values 54that are only a few least significant bits - computation noise. 55Others, often those for which analytical solutions are not available, 56require approximations and iteration: 57these may lose several decimal digits of precision. 58 59Much larger loss of precision can occur for [@http://en.wikipedia.org/wiki/Boundary_case boundary] 60or [@http://en.wikipedia.org/wiki/Corner_case corner cases], 61often caused by [@http://en.wikipedia.org/wiki/Loss_of_significance cancellation errors]. 62 63(Some of the worst and most common examples of 64[@http://en.wikipedia.org/wiki/Loss_of_significance cancellation error or loss of significance] 65can be avoided by using __complements: see __why_complements). 66 67If you require a value which is as accurate as can be represented in the floating-point type, 68and is thus the closest representable value and has an error less than 1/2 a 69[@http://en.wikipedia.org/wiki/Least_significant_bit least significant bit] or 70[@http://en.wikipedia.org/wiki/Unit_in_the_last_place ulp] 71it may be useful to use a higher-precision type, 72for example, `cpp_dec_float_50`, to generate this value. 73Conversion of this value to a built-in floating-point type ('float', `double` or `long double`) 74will not cause any further loss of precision. 75A decimal digit string will also be 'read' precisely by the compiler 76into a built-in floating-point type to the nearest representable value. 77 78[note In contrast, reading a value from an `std::istream` into a built-in floating-point type 79is [*not guaranteed] by the C++ Standard to give the nearest representable value.] 80 81William Kahan coined the term 82[@http://en.wikipedia.org/wiki/Rounding#The_table-maker.27s_dilemma Table-Maker's Dilemma] 83for the problem of correctly rounding functions. 84Using a much higher precision (50 or 100 decimal digits) 85is a practical way of generating (almost always) correctly rounded values. 86 87[endsect] [/section:why_high_precision Why use a high-precision library rather than built-in floating-point types?] 88 89[section:use_multiprecision Using Boost.Multiprecision] 90 91[*All new projects are recommended to use __multiprecision.] 92 93[import ../../example/big_seventh.cpp] 94 95[big_seventh_example_1] 96 97[import ../../example/fft_sines_table.cpp] 98 99[fft_sines_table_example_1] 100 101The table output is: 102 103[fft_sines_table_example_output] 104 105[fft_sines_table_example_check] 106 107 108[/TODO another example needed here] 109 110[/import ../../example/ibeta_mp_example.cpp] 111 112[/ibeta_mp_example_1] 113 114[/The program output is:] 115 116[/ibeta_mp_output_1] 117 118[endsect] [/section:use_multiprecision Using Boost.Multiprecision] 119 120[section:float128 Using with GCC's __float128 datatype] 121 122At present support for GCC's native `__float128` datatype is extremely limited: the numeric constants 123will all work with that type, and that's about it. If you want to use the distributions or special 124functions then you will need to provide your own wrapper header that: 125 126* Provides std::numeric_limits<__float128> support. 127* Provides overloads of the standard library math function for type `__float128`and which forward to the libquadmath equivalents. 128 129Ultimately these facilities should be provided by GCC and libstdc++. 130 131[endsect] 132 133[section:use_mpfr Using With MPFR or GMP - High-Precision Floating-Point Library] 134 135The special functions and tools in this library can be used with 136[@http://www.mpfr.org MPFR] (an arbitrary precision number type based on the __GMP), 137either via the bindings in [@../../../../boost/math/bindings/mpfr.hpp boost/math/bindings/mpfr.hpp], 138or via [@../../../../boost/math/bindings/mpfr.hpp boost/math/bindings/mpreal.hpp]. 139 140[*New projects are recommended to use __multiprecision with GMP/MPFR backend instead.] 141 142In order to use these bindings you will need to have installed [@http://www.mpfr.org MPFR] 143plus its dependency the [@http://gmplib.org GMP library]. You will also need one of the 144two supported C++ wrappers for MPFR: 145[@http://math.berkeley.edu/~wilken/code/gmpfrxx/ gmpfrxx (or mpfr_class)], 146or [@http://www.holoborodko.com/pavel/mpfr/ mpfr-C++ (mpreal)]. 147 148Unfortunately neither `mpfr_class` nor `mpreal` quite satisfy our conceptual requirements, 149so there is a very thin set of additional interfaces and some helper traits defined in 150[@../../../../boost/math/bindings/mpfr.hpp boost/math/bindings/mpfr.hpp] and 151[@../../../../boost/math/bindings/mpreal.hpp boost/math/bindings/mpreal.hpp] 152that you should use in place of including 'gmpfrxx.h' or 'mpreal.h' directly. 153The classes `mpfr_class` or `mpreal` are 154then usable unchanged once this header is included, so for example `mpfr_class`'s 155performance-enhancing expression templates are preserved and fully supported by this library: 156 157 #include <boost/math/bindings/mpfr.hpp> 158 #include <boost/math/special_functions/gamma.hpp> 159 160 int main() 161 { 162 mpfr_class::set_dprec(500); // 500 bit precision 163 // 164 // Note that the argument to tgamma is 165 // an expression template - that's just fine here. 166 // 167 mpfr_class v = boost::math::tgamma(sqrt(mpfr_class(2))); 168 std::cout << std::setprecision(50) << v << std::endl; 169 } 170 171Alternatively use with `mpreal` would look like: 172 173 #include <boost/math/bindings/mpreal.hpp> 174 #include <boost/math/special_functions/gamma.hpp> 175 176 int main() 177 { 178 mpfr::mpreal::set_precision(500); // 500 bit precision 179 mpfr::mpreal v = boost::math::tgamma(sqrt(mpfr::mpreal(2))); 180 std::cout << std::setprecision(50) << v << std::endl; 181 } 182 183For those functions that are based upon the __lanczos, the bindings 184defines a series of approximations with up to 61 terms and accuracy 185up to approximately 3e-113. This therefore sets the upper limit for accuracy 186to the majority of functions defined this library when used with either `mpfr_class` or `mpreal`. 187 188There is a concept checking test program for mpfr support 189[@../../../../libs/math/test/mpfr_concept_check.cpp here] and 190[@../../../../libs/math/test/mpreal_concept_check.cpp here]. 191 192[endsect] [/section:use_mpfr Using With MPFR / GMP - a High-Precision Floating-Point Library] 193 194[section:e_float Using e_float Library] 195 196__multiprecision was a development from the __e_float library by Christopher Kormanyos. 197 198e_float can still be used with Boost.Math library via the header: 199 200 <boost/math/bindings/e_float.hpp> 201 202And the type `boost::math::ef::e_float`: 203this type is a thin wrapper class around ::e_float which provides the necessary 204syntactic sugar to make everything "just work". 205 206There is also a concept checking test program for e_float support 207[@../../../../libs/math/test/e_float_concept_check.cpp here]. 208 209[*New projects are recommended to use __multiprecision with `cpp_float` backend instead.] 210 211[endsect] [/section:e_float Using e_float Library] 212 213[section:use_ntl Using NTL Library] 214 215[@http://shoup.net/ntl/doc/RR.txt NTL::RR] 216(an arbitrarily-fixed precision floating-point number type), 217can be used via the bindings in 218[@../../../../boost/math/bindings/rr.hpp boost/math/bindings/rr.hpp]. 219For details, see [@http://shoup.net/ntl/ NTL: A Library for doing Number Theory by 220Victor Shoup]. 221 222[*New projects are recommended to use __multiprecision instead.] 223 224Unfortunately `NTL::RR` doesn't quite satisfy our conceptual requirements, 225so there is a very thin wrapper class `boost::math::ntl::RR` defined in 226[@../../../../boost/math/bindings/rr.hpp boost/math/bindings/rr.hpp] that you 227should use in place of `NTL::RR`. The class is intended to be a drop-in 228replacement for the "real" NTL::RR that adds some syntactic sugar to keep 229this library happy, plus some of the standard library functions not implemented 230in NTL. 231 232For those functions that are based upon the __lanczos, the bindings 233defines a series of approximations with up to 61 terms and accuracy 234up to approximately 3e-113. This therefore sets the upper limit for accuracy 235to the majority of functions defined this library when used with `NTL::RR`. 236 237There is a concept checking test program for NTL support 238[@../../../../libs/math/test/ntl_concept_check.cpp here]. 239 240 241[endsect] [/section:use_ntl Using With NTL - a High-Precision Floating-Point Library] 242 243[section:using_test Using without expression templates for Boost.Test and others] 244 245As noted in the __multiprecision documentation, certain program constructs will not compile 246when using expression templates. One example that many users may encounter 247is Boost.Test (1.54 and earlier) when using macro BOOST_CHECK_CLOSE and BOOST_CHECK_CLOSE_FRACTION. 248 249If, for example, you wish to use any multiprecision type like `cpp_dec_float_50` 250in place of `double` to give more precision, 251you will need to override the default `boost::multiprecision::et_on` with 252`boost::multiprecision::et_off`. 253 254[import ../../example/test_cpp_float_close_fraction.cpp] 255 256[expression_template_1] 257 258A full example code is at [@../../example/test_cpp_float_close_fraction.cpp test_cpp_float_close_fraction.cpp] 259 260[endsect] [/section:using_test Using without expression templates for Boost.Test and others] 261 262[endsect] [/section:high_precision Using With High-Precision Floating-Point Libraries] 263 264 265[section:concepts Conceptual Requirements for Real Number Types] 266 267The functions, and statistical distributions in this library can be used with 268any type /RealType/ that meets the conceptual requirements given below. All 269the built-in floating-point types will meet these requirements. 270User-defined types that meet the requirements can also be used. 271 272For example, with [link math_toolkit.high_precision.use_ntl a thin wrapper class] 273one of the types provided with [@http://shoup.net/ntl/ NTL (RR)] can be used. 274But now that __multiprecision library is available, 275this has become the reference real number type. 276 277Submissions of binding to other extended precision types would also still be welcome. 278 279The guiding principal behind these requirements is that a /RealType/ 280behaves just like a built-in floating-point type. 281 282[h4 Basic Arithmetic Requirements] 283 284These requirements are common to all of the functions in this library. 285 286In the following table /r/ is an object of type `RealType`, /cr/ and 287/cr2/ are objects 288of type `const RealType`, and /ca/ is an object of type `const arithmetic-type` 289(arithmetic types include all the built in integers and floating point types). 290 291[table 292[[Expression][Result Type][Notes]] 293[[`RealType(cr)`][RealType] 294 [RealType is copy constructible.]] 295[[`RealType(ca)`][RealType] 296 [RealType is copy constructible from the arithmetic types.]] 297[[`r = cr`][RealType&][Assignment operator.]] 298[[`r = ca`][RealType&][Assignment operator from the arithmetic types.]] 299[[`r += cr`][RealType&][Adds cr to r.]] 300[[`r += ca`][RealType&][Adds ar to r.]] 301[[`r -= cr`][RealType&][Subtracts cr from r.]] 302[[`r -= ca`][RealType&][Subtracts ca from r.]] 303[[`r *= cr`][RealType&][Multiplies r by cr.]] 304[[`r *= ca`][RealType&][Multiplies r by ca.]] 305[[`r /= cr`][RealType&][Divides r by cr.]] 306[[`r /= ca`][RealType&][Divides r by ca.]] 307[[`-r`][RealType][Unary Negation.]] 308[[`+r`][RealType&][Identity Operation.]] 309[[`cr + cr2`][RealType][Binary Addition]] 310[[`cr + ca`][RealType][Binary Addition]] 311[[`ca + cr`][RealType][Binary Addition]] 312[[`cr - cr2`][RealType][Binary Subtraction]] 313[[`cr - ca`][RealType][Binary Subtraction]] 314[[`ca - cr`][RealType][Binary Subtraction]] 315[[`cr * cr2`][RealType][Binary Multiplication]] 316[[`cr * ca`][RealType][Binary Multiplication]] 317[[`ca * cr`][RealType][Binary Multiplication]] 318[[`cr / cr2`][RealType][Binary Subtraction]] 319[[`cr / ca`][RealType][Binary Subtraction]] 320[[`ca / cr`][RealType][Binary Subtraction]] 321[[`cr == cr2`][bool][Equality Comparison]] 322[[`cr == ca`][bool][Equality Comparison]] 323[[`ca == cr`][bool][Equality Comparison]] 324[[`cr != cr2`][bool][Inequality Comparison]] 325[[`cr != ca`][bool][Inequality Comparison]] 326[[`ca != cr`][bool][Inequality Comparison]] 327[[`cr <= cr2`][bool][Less than equal to.]] 328[[`cr <= ca`][bool][Less than equal to.]] 329[[`ca <= cr`][bool][Less than equal to.]] 330[[`cr >= cr2`][bool][Greater than equal to.]] 331[[`cr >= ca`][bool][Greater than equal to.]] 332[[`ca >= cr`][bool][Greater than equal to.]] 333[[`cr < cr2`][bool][Less than comparison.]] 334[[`cr < ca`][bool][Less than comparison.]] 335[[`ca < cr`][bool][Less than comparison.]] 336[[`cr > cr2`][bool][Greater than comparison.]] 337[[`cr > ca`][bool][Greater than comparison.]] 338[[`ca > cr`][bool][Greater than comparison.]] 339[[`boost::math::tools::digits<RealType>()`][int] 340 [The number of digits in the significand of RealType.]] 341[[`boost::math::tools::max_value<RealType>()`][RealType] 342 [The largest representable number by type RealType.]] 343[[`boost::math::tools::min_value<RealType>()`][RealType] 344 [The smallest representable number by type RealType.]] 345[[`boost::math::tools::log_max_value<RealType>()`][RealType] 346 [The natural logarithm of the largest representable number by type RealType.]] 347[[`boost::math::tools::log_min_value<RealType>()`][RealType] 348 [The natural logarithm of the smallest representable number by type RealType.]] 349[[`boost::math::tools::epsilon<RealType>()`][RealType] 350 [The machine epsilon of RealType.]] 351] 352 353Note that: 354 355# The functions `log_max_value` and `log_min_value` can be 356synthesised from the others, and so no explicit specialisation is required. 357# The function `epsilon` can be synthesised from the others, so no 358explicit specialisation is required provided the precision 359of RealType does not vary at runtime (see the header 360[@../../../../boost/math/bindings/rr.hpp boost/math/bindings/rr.hpp] 361for an example where the precision does vary at runtime). 362# The functions `digits`, `max_value` and `min_value`, all get synthesised 363automatically from `std::numeric_limits`. However, if `numeric_limits` 364is not specialised for type RealType, then you will get a compiler error 365when code tries to use these functions, /unless/ you explicitly specialise them. 366For example if the precision of RealType varies at runtime, then 367`numeric_limits` support may not be appropriate, see 368[@../../../../boost/math/bindings/rr.hpp boost/math/bindings/rr.hpp] for examples. 369 370[warning 371If `std::numeric_limits<>` is *not specialized* 372for type /RealType/ then the default float precision of 6 decimal digits 373will be used by other Boost programs including: 374 375Boost.Test: giving misleading error messages like 376 377['"difference between {9.79796} and {9.79796} exceeds 5.42101e-19%".] 378 379Boost.LexicalCast and Boost.Serialization when converting the number 380to a string, causing potentially serious loss of accuracy on output. 381 382Although it might seem obvious that RealType should require `std::numeric_limits` 383to be specialized, this is not sensible for 384`NTL::RR` and similar classes where the number of digits is a runtime 385parameter (where as for `numeric_limits` it has to be fixed at compile time). 386] 387 388[h4 Standard Library Support Requirements] 389 390Many (though not all) of the functions in this library make calls 391to standard library functions, the following table summarises the 392requirements. Note that most of the functions in this library 393will only call a small subset of the functions listed here, so if in 394doubt whether a user defined type has enough standard library 395support to be useable the best advise is to try it and see! 396 397In the following table /r/ is an object of type `RealType`, 398/cr1/ and /cr2/ are objects of type `const RealType`, and 399/i/ is an object of type `int`. 400 401[table 402[[Expression][Result Type]] 403[[`fabs(cr1)`][RealType]] 404[[`abs(cr1)`][RealType]] 405[[`ceil(cr1)`][RealType]] 406[[`floor(cr1)`][RealType]] 407[[`exp(cr1)`][RealType]] 408[[`pow(cr1, cr2)`][RealType]] 409[[`sqrt(cr1)`][RealType]] 410[[`log(cr1)`][RealType]] 411[[`frexp(cr1, &i)`][RealType]] 412[[`ldexp(cr1, i)`][RealType]] 413[[`cos(cr1)`][RealType]] 414[[`sin(cr1)`][RealType]] 415[[`asin(cr1)`][RealType]] 416[[`tan(cr1)`][RealType]] 417[[`atan(cr1)`][RealType]] 418[[`fmod(cr1)`][RealType]] 419[[`round(cr1)`][RealType]] 420[[`iround(cr1)`][int]] 421[[`trunc(cr1)`][RealType]] 422[[`itrunc(cr1)`][int]] 423] 424 425Note that the table above lists only those standard library functions known to 426be used (or likely to be used in the near future) by this library. 427The following functions: `acos`, `atan2`, `fmod`, `cosh`, `sinh`, `tanh`, `log10`, 428`lround`, `llround`, `ltrunc`, `lltrunc` and `modf` 429are not currently used, but may be if further special functions are added. 430 431Note that the `round`, `trunc` and `modf` functions are not part of the 432current C++ standard: they are part of the additions added to C99 which will 433likely be in the next C++ standard. There are Boost versions of these provided 434as a backup, and the functions are always called unqualified so that 435argument-dependent-lookup can take place. 436 437In addition, for efficient and accurate results, a __lanczos is highly desirable. 438You may be able to adapt an existing approximation from 439[@../../../../boost/math/special_functions/lanczos.hpp 440boost/math/special_functions/lanczos.hpp] or 441[@../../../../boost/math/bindings/detail/big_lanczos.hpp 442boost/math/bindings/detail/big_lanczos.hpp]: 443in the former case you will need change 444static_cast's to lexical_cast's, and the constants to /strings/ 445(in order to ensure the coefficients aren't truncated to long double) 446and then specialise `lanczos_traits` for type T. Otherwise you may have to hack 447[@../../tools/lanczos_generator.cpp 448libs/math/tools/lanczos_generator.cpp] to find a suitable 449approximation for your RealType. The code will still compile if you don't do 450this, but both accuracy and efficiency will be greatly compromised in any 451function that makes use of the gamma\/beta\/erf family of functions. 452 453[endsect] [/section: ] 454 455[section:dist_concept Conceptual Requirements for Distribution Types] 456 457A /DistributionType/ is a type that implements the following conceptual 458requirements, and encapsulates a statistical distribution. 459 460Please note that this documentation should not be used as a substitute 461for the 462[link math_toolkit.dist_ref reference documentation], and 463[link math_toolkit.stat_tut tutorial] of the statistical 464distributions. 465 466In the following table, /d/ is an object of type `DistributionType`, 467/cd/ is an object of type `const DistributionType` and /cr/ is an 468object of a type convertible to `RealType`. 469 470[table 471[[Expression][Result Type][Notes]] 472[[DistributionType::value_type][RealType] 473 [The real-number type /RealType/ upon which the distribution operates.]] 474[[DistributionType::policy_type][RealType] 475 [The __Policy to use when evaluating functions that depend on this distribution.]] 476[[d = cd][Distribution&][Distribution types are assignable.]] 477[[Distribution(cd)][Distribution][Distribution types are copy constructible.]] 478[[pdf(cd, cr)][RealType][Returns the PDF of the distribution.]] 479[[cdf(cd, cr)][RealType][Returns the CDF of the distribution.]] 480[[cdf(complement(cd, cr))][RealType] 481 [Returns the complement of the CDF of the distribution, 482 the same as: `1-cdf(cd, cr)`]] 483[[quantile(cd, cr)][RealType][Returns the quantile (or percentile) of the distribution.]] 484[[quantile(complement(cd, cr))][RealType] 485 [Returns the quantile (or percentile) of the distribution, starting from 486 the complement of the probability, the same as: `quantile(cd, 1-cr)`]] 487[[chf(cd, cr)][RealType][Returns the cumulative hazard function of the distribution.]] 488[[hazard(cd, cr)][RealType][Returns the hazard function of the distribution.]] 489[[kurtosis(cd)][RealType][Returns the kurtosis of the distribution.]] 490[[kurtosis_excess(cd)][RealType][Returns the kurtosis excess of the distribution.]] 491[[mean(cd)][RealType][Returns the mean of the distribution.]] 492[[mode(cd)][RealType][Returns the mode of the distribution.]] 493[[skewness(cd)][RealType][Returns the skewness of the distribution.]] 494[[standard_deviation(cd)][RealType][Returns the standard deviation of the distribution.]] 495[[variance(cd)][RealType][Returns the variance of the distribution.]] 496] 497 498[endsect] 499 500[section:archetypes Conceptual Archetypes for Reals and Distributions] 501 502There are a few concept archetypes available: 503 504* Real concept for floating-point types. 505* distribution Concept for statistical distributions. 506 507[h5 Real concept] 508 509`std_real_concept` is an archetype for theReal types, 510including the built-in float, double, long double. 511 512``#include <boost/concepts/std_real_concept.hpp>`` 513 514 namespace boost{ 515 namespace math{ 516 namespace concepts 517 { 518 class std_real_concept; 519 } 520 }} // namespaces 521 522 523The main purpose in providing this type is to verify 524that standard library functions are found via a using declaration - 525bringing those functions into the current scope - 526and not just because they happen to be in global scope. 527 528In order to ensure that a call to say `pow` can be found 529either via argument dependent lookup, or failing that then 530in the std namespace: all calls to standard library functions 531are unqualified, with the std:: versions found via a `using` declaration 532to make them visible in the current scope. Unfortunately it's all 533to easy to forget the `using` declaration, and call the double version of 534the function that happens to be in the global scope by mistake. 535 536For example if the code calls ::pow rather than std::pow, 537the code will cleanly compile, but truncation of long doubles to 538double will cause a significant loss of precision. 539In contrast a template instantiated with std_real_concept will *only* 540compile if the all the standard library functions used have 541been brought into the current scope with a using declaration. 542 543[h6 Testing the real concept] 544 545There is a test program 546[@../../test/std_real_concept_check.cpp libs/math/test/std_real_concept_check.cpp] 547that instantiates every template in this library with type 548`std_real_concept` to verify its usage of standard library functions. 549 550``#include <boost/math/concepts/real_concept.hpp>`` 551 552 namespace boost{ 553 namespace math{ 554 namespace concepts{ 555 556 class real_concept; 557 558 }}} // namespaces 559 560`real_concept` is an archetype for 561[link math_toolkit.concepts user defined real types], 562it declares its standard library functions in its own 563namespace: these will only be found if they are called unqualified 564allowing argument dependent lookup to locate them. In addition 565this type is useable at runtime: 566this allows code that would not otherwise be exercised by the built-in 567floating point types to be tested. There is no std::numeric_limits<> 568support for this type, since numeric_limits is not a conceptual requirement 569for [link math_toolkit.concepts RealType]s. 570 571NTL RR is an example of a type meeting the requirements that this type 572models, but note that use of a thin wrapper class is required: refer to 573[link math_toolkit.high_precision.use_ntl "Using With NTL - a High-Precision Floating-Point Library"]. 574 575There is no specific test case for type `real_concept`, instead, since this 576type is usable at runtime, each individual test case as well as testing 577`float`, `double` and `long double`, also tests `real_concept`. 578 579[h6 Distribution Concept] 580 581Distribution Concept models statistical distributions. 582 583``#include <boost/math/concepts/distribution.hpp>`` 584 585 namespace boost{ 586 namespace math{ 587 namespace concepts 588 { 589 template <class RealType> 590 class distribution_archetype; 591 592 template <class Distribution> 593 struct DistributionConcept; 594 595 }}} // namespaces 596 597The class template `distribution_archetype` is a model of the 598[link math_toolkit.dist_concept Distribution concept]. 599 600The class template `DistributionConcept` is a 601[@../../../../libs/concept_check/index.html concept checking class] 602for distribution types. 603 604[h6 Testing the distribution concept] 605 606The test program 607[@../../test/compile_test/distribution_concept_check.cpp distribution_concept_check.cpp] 608is responsible for using `DistributionConcept` to verify that all the 609distributions in this library conform to the 610[link math_toolkit.dist_concept Distribution concept]. 611 612The class template `DistributionConcept` verifies the existence 613(but not proper function) of the non-member accessors 614required by the [link math_toolkit.dist_concept Distribution concept]. 615These are checked by calls like 616 617v = pdf(dist, x); // (Result v is ignored). 618 619And in addition, those that accept two arguments do the right thing when the 620arguments are of different types (the result type is always the same as the 621distribution's value_type). (This is implemented by some additional 622forwarding-functions in derived_accessors.hpp, so that there is no need for 623any code changes. Likewise boilerplate versions of the 624hazard\/chf\/coefficient_of_variation functions are implemented in 625there too.) 626 627[endsect] [/section:archetypes Conceptual Archetypes for Reals and Distributions] 628[/ 629 Copyright 2006, 2010, 2012 John Maddock and Paul A. Bristow. 630 Distributed under the Boost Software License, Version 1.0. 631 (See accompanying file LICENSE_1_0.txt or copy at 632 http://www.boost.org/LICENSE_1_0.txt). 633] 634 635 636 637 638