generators.qbk 6.1 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192
  1. [/
  2. / Copyright (c) 2009-2010 Steven Watanabe
  3. /
  4. / Distributed under the Boost Software License, Version 1.0. (See
  5. / accompanying file LICENSE_1_0.txt or copy at
  6. / http://www.boost.org/LICENSE_1_0.txt)
  7. ]
  8. This library provides several [prng pseudo-random number generators]. The
  9. quality of a [prng pseudo random number generator] crucially depends on both
  10. the algorithm and its parameters. This library implements the algorithms as
  11. class templates with template value parameters, hidden in
  12. `namespace boost::random`. Any particular choice of parameters is represented
  13. as the appropriately specializing `typedef` in `namespace boost`.
  14. [prng Pseudo-random number generators] should not be constructed (initialized)
  15. frequently during program execution, for two reasons. First, initialization
  16. requires full initialization of the internal state of the generator. Thus,
  17. generators with a lot of internal state (see below) are costly to initialize.
  18. Second, initialization always requires some value used as a "seed" for the
  19. generated sequence. It is usually difficult to obtain several good seed
  20. values. For example, one method to obtain a seed is to determine the current
  21. time at the highest resolution available, e.g. microseconds or nanoseconds.
  22. When the [prng pseudo-random number generator] is initialized again with the
  23. then-current time as the seed, it is likely that this is at a near-constant
  24. (non-random) distance from the time given as the seed for first
  25. initialization. The distance could even be zero if the resolution of the
  26. clock is low, thus the generator re-iterates the same sequence of random
  27. numbers. For some applications, this is inappropriate.
  28. Note that all [prng pseudo-random number generators] described below are
  29. __CopyConstructible and __Assignable. Copying or assigning a generator will
  30. copy all its internal state, so the original and the copy will generate the
  31. identical sequence of random numbers. Often, such behavior is not wanted. In
  32. particular, beware of the algorithms from the standard library such as
  33. `std::generate`. They take a functor argument by value, thereby invoking the
  34. copy constructor when called.
  35. The following table gives an overview of some characteristics of the
  36. generators. The cycle length is a rough estimate of the quality of the
  37. generator; the approximate relative speed is a performance measure, higher
  38. numbers mean faster random number generation.
  39. [table generators
  40. [[generator] [length of cycle] [approx. memory requirements] [approx. speed compared to fastest] [comment]]
  41. [[__minstd_rand0] [2[sup 31]-2] [`sizeof(int32_t)`] [[minstd_rand0_speed]] [-]]
  42. [[__minstd_rand] [2[sup 31]-2] [`sizeof(int32_t)`] [[minstd_rand_speed]] [-]]
  43. [[__rand48][2[sup 48]-1] [`sizeof(uint64_t)`] [[rand48_speed]] [-]]
  44. [[__ecuyer1988] [approx. 2[sup 61]] [`2*sizeof(int32_t)`] [[ecuyer_combined_speed]] [-]]
  45. [[__knuth_b] [?] [`257*sizeof(uint32_t)`] [[knuth_b_speed]] [-]]
  46. [[__kreutzer1986] [?] [`98*sizeof(uint32_t)`] [[kreutzer1986_speed]] [-]]
  47. [[__taus88] [~2[sup 88]] [`3*sizeof(uint32_t)`] [[taus88_speed]] [-]]
  48. [[__hellekalek1995] [2[sup 31]-1] [`sizeof(int32_t)`] [[hellekalek1995__inversive__speed]] [good uniform distribution in several dimensions]]
  49. [[__mt11213b] [2[sup 11213]-1] [`352*sizeof(uint32_t)`] [[mt11213b_speed]] [good uniform distribution in up to 350 dimensions]]
  50. [[__mt19937] [2[sup 19937]-1] [`625*sizeof(uint32_t)`] [[mt19937_speed]] [good uniform distribution in up to 623 dimensions]]
  51. [[__mt19937_64] [2[sup 19937]-1] [`312*sizeof(uint64_t)`] [[mt19937_64_speed]] [good uniform distribution in up to 311 dimensions]]
  52. [[__lagged_fibonacci607] [~2[sup 32000]] [`607*sizeof(double)`] [[lagged_fibonacci607_speed]] [-]]
  53. [[__lagged_fibonacci1279] [~2[sup 67000]] [`1279*sizeof(double)`] [[lagged_fibonacci1279_speed]] [-]]
  54. [[__lagged_fibonacci2281] [~2[sup 120000]] [`2281*sizeof(double)`] [[lagged_fibonacci2281_speed]] [-]]
  55. [[__lagged_fibonacci3217] [~2[sup 170000]] [`3217*sizeof(double)`] [[lagged_fibonacci3217_speed]] [-]]
  56. [[__lagged_fibonacci4423] [~2[sup 230000]] [`4423*sizeof(double)`] [[lagged_fibonacci4423_speed]] [-]]
  57. [[__lagged_fibonacci9689] [~2[sup 510000]] [`9689*sizeof(double)`] [[lagged_fibonacci9689_speed]] [-]]
  58. [[__lagged_fibonacci19937] [~2[sup 1050000]] [`19937*sizeof(double)`] [[lagged_fibonacci19937_speed]] [-]]
  59. [[__lagged_fibonacci23209] [~2[sup 1200000]] [`23209*sizeof(double)`] [[lagged_fibonacci23209_speed]] [-]]
  60. [[__lagged_fibonacci44497] [~2[sup 2300000]] [`44497*sizeof(double)`] [[lagged_fibonacci44497_speed]] [-]]
  61. [[__ranlux3] [~10[sup 171]] [`24*sizeof(int)`] [[ranlux3_speed]] [-]]
  62. [[__ranlux4] [~10[sup 171]] [`24*sizeof(int)`] [[ranlux4_speed]] [-]]
  63. [[__ranlux64_3] [~10[sup 171]] [`24*sizeof(int64_t)`] [[ranlux64_3_speed]] [-]]
  64. [[__ranlux64_4] [~10[sup 171]] [`24*sizeof(int64_t)`] [[ranlux64_4_speed]] [-]]
  65. [[__ranlux3_01] [~10[sup 171]] [`24*sizeof(float)`] [[ranlux3_speed]] [-]]
  66. [[__ranlux4_01] [~10[sup 171]] [`24*sizeof(float)`] [[ranlux4_speed]] [-]]
  67. [[__ranlux64_3_01] [~10[sup 171]] [`24*sizeof(double)`] [[ranlux64_3_speed]] [-]]
  68. [[__ranlux64_4_01] [~10[sup 171]] [`24*sizeof(double)`] [[ranlux64_4_speed]] [-]]
  69. [[__ranlux24] [~10[sup 171]] [`24*sizeof(uint32_t)`] [[ranlux24_speed]] [-]]
  70. [[__ranlux48] [~10[sup 171]] [`12*sizeof(uint64_t)`] [[ranlux48_speed]] [-]]
  71. ]
  72. As observable from the table, there is generally a quality/performance/memory
  73. trade-off to be decided upon when choosing a random-number generator. The
  74. multitude of generators provided in this library allows the application
  75. programmer to optimize the trade-off with regard to his application domain.
  76. Additionally, employing several fundamentally different random number
  77. generators for a given application of Monte Carlo simulation will improve
  78. the confidence in the results.
  79. If the names of the generators don't ring any bell and you have no idea
  80. which generator to use, it is reasonable to employ __mt19937 for a start: It
  81. is fast and has acceptable quality.
  82. [note These random number generators are not intended for use in applications
  83. where non-deterministic random numbers are required. See __random_device
  84. for a choice of (hopefully) non-deterministic random number generators.]