Talk:Mersenne Twister

message: i added a sentence about why the MT can't be used for cryptography — observing the sequence of iterates for long enough allows one to predict or independently calulate all future iterates.  dunno if this is sufficient.  Lunch 01:23, 16 March 2006 (UTC)
replies: text: I do not understand what does that mean exactly. Does this prediction require tto know that the MT is used (and no other PRNG)? How is the observation acutually done, how must the numbers been analysed? And why doesn't this contradict the equidistribution?--SiriusB 14:56, 14 May 2007 (UTC)
replies: text: There's nothing odd about predictable but still equidistributed. As a very simple example, consider the sequence 1, 2, ..., 500, 1, 2, ..., which repeats indefinitely. This is an equidistributed sequence (each value from 1-500 appears the same number of times) but if I were to tell you the current number in the sequence, you would immediately be able to give the next number in the sequence. —Lowellian (reply) 20:58, 22 May 2007 (UTC)
replies: text: OK, but this far from being a random-like distribution. Let's say it in other words: "Random-like" and "predicrable" should contradict each other. But the random-like distribution of the MT is said to be among the best of all, so how can a random-like distribution still be predictable? Or is it only predictable if one knows that the MT is used (and how it works, of course) and the predictability is reduced to finding the correct seed?--SiriusB 10:57, 23 May 2007 (UTC)
replies: text: First of all, "random-like" and "predictable" are not contradictory. A good pseudorandom number generator seems "random-like," but by definition of its pseudorandomness, is also predictable if you understand the generating algorithm and have the seed. If you observe about 600-something values of MT, it is possible to determine where in the MT sequence you are, and from there determine future values. —Lowellian (reply) 03:10, 27 May 2007 (UTC)
thread_title:  cryptography and the MT 

message: The article says:
"The "twist" is a transformation which assures equidistribution of the generated numbers in 623 dimensions (linear congruential generators can at best manage reasonable distribution in 5 dimensions)"
I think this is probably wrong. The equidistribution in 623 dimensions is also attained by a linear congruential generator provided it is as big as Mersenne Twister, and that it is based on a primitive polynomial. In fact all the widely discussed good properties of Mersenne Twister are shared by a such a construction. There are a few good things the "twist" achieves but they are very subtle (perhaps too much so for an encyclopedia article). 203.164.223.124 02:49, 28 April 2006 (UTC)
thread_title:  The "twist" and equidistribution 

message: The article says:
"It is faster than all but the most statistically unsound generators."
Not really. It is quite fast. It is difficult to make a generator this good that runs faster. But a lagged fibonacci generator with sufficiently large lags can run quite a lot faster, and has good enough properties for many purposes. A lagged fibonacci generator with 4 taps (instead of the usual 2) is likely at least as fast as MT and behaves quite well. The construction used in SPRNG with two lagged fibonnaci generators combined with right shift and XOR is also very fast and very good. None of these have the proveable nice properties of the twister, but in practice i would not call them "most statistically unsound".
BTW the free source code distributed by the original inventors of MT is kind of acceptibly quick, but could be a lot faster if optimised, especially for a particular machine. But even when optimised it will be a lot slower than lagged fibonacci. 203.164.223.124 02:49, 28 April 2006 (UTC)
thread_title:  Speed 

message: The proveable equidistribution in 623 dimensions may be a red herring. It only applies totalled over the whole period of the generator. The period is so huge that it is unlikely to be used in any real application. It is actually possible to achieve the same guarantee for some really bad generators.
Here's one: take a unsigned binary number with 623*32 = 19936 bits. Initialise it to some value as the seed. Return successive 32 bit sections from the number as pseudo-random return values. When the end of the number is reached, increment the number and start back at the first 32 bit section. Over the whole period, this has equidistribution in 623 dimensions. Over any data set you would use in practice, it sucks.
Mersenne Twister seems to be very well behaved in practice, but this has very little to do with the theoretical guarantee. 203.164.223.124 02:49, 28 April 2006 (UTC)
replies: text: What you described is equidistributed in exactly 623 dimensions; from what I understand this algorithm has proven equidistribution in up to 623 dimensions, a much stronger properly which isn't accomplished by your algorithm. --192.198.152.98 15:27, 13 May 2007 (UTC)
thread_title:  equidistribution 

message: I'm somewhat puzzled by the "applications" paragraph. What does it mean that 624 observations allows one to predict the future iterates?
Are there any known issues with some seeds?
(Please try to be simple, I'm not really in those things)
MaxDZ8 talk 14:32, 26 October 2006 (UTC)
replies: text: Tempering function is bijective. So inverse function exists. So we can rebuild internal vectors from 624 outputs. Then we can run MT algorism to get next sequence.133.41.131.128 01:11, 14 March 2007 (UTC)
thread_title:  I don't undestand... 

message: MT generates 624 numbers at once, but it's for speed.
Pseudo code should show algorithm clearly without considering speed.
I don't know the grammer of pseudo code, so I show it in C:
    unsigned long genrand_int32(void)
    {
        unsigned long y;
        static unsigned long mag01[2]={0x0UL, MATRIX_A};
        /* mag01[x] = x * MATRIX_A  for x=0,1 */
        mti = mti % N;
        y = (mt[mti] & UPPER_MASK) | (mt[(mti + 1) % N] & LOWER_MASK);
        mt[mti] = mt[(mti + M) % N] ^ (y >> 1) ^ mag01[y & 0x1UL];
        y = mt[mti];
        mti++;
        /* Tempering */
        y ^= (y >> 11);
        y ^= (y << 7) & 0x9d2c5680UL;
        y ^= (y << 15) & 0xefc60000UL;
        y ^= (y >> 18);
        return y;
    }
—The preceding unsigned comment was added by 133.41.131.128 (talk) 04:32, 27 March 2007 (UTC)
replies: text: There is no grammar for pseudo-code, it's just supposed to be readable by all human programmers but not by a computer program. It should look like Pascal but you're free to use things like shift 5 bits to the left() while this is clearly a syntax error in Pascal or C. 88.170.208.244 (talk) 11:44, 12 August 2008 (UTC)
thread_title: Pseudo code

message: When the article talks about the period, it states that 
"in practice, there is little reason to use larger ones, as most applications do not require 2^19937 unique combinations".
 This seems like misinformation. On the Pseudorandom Number Generator page, it says that 2^19937 combinations is 
"likely far more than the number of computations which can be performed within the entire future existence of the universe)".
  I think this statement should be rephrased.
142.162.90.179 19:09, 10 April 2007 (UTC)
replies: text: Which statement do you think should be rephrased, the former or the latter? I see no problem with the former statement. It is perfectly true that most applications do not require 2^19937 unique combinations. If it is the latter statement you see a problem with, you should discuss it on Talk:Pseudorandom number generator, not here, since that is the page on which the statement appears. —Lowellian (reply) 20:47, 22 May 2007 (UTC)
replies: text: I suggest saying:
"This period exceeds the need of any practical application." Cuddlyable3 10:39, 27 June 2007 (UTC)

text: Not at all. The period of MT makes many practical applications unsuitable. For example the python function random.shuffle is limited due to the period of MT.  ,  Shabda 09:26, 9 August 2007 (UTC)
replies: text: That's not a practical limitation. It's easier to see that with randomly generated text than permutations: most texts can never come out of a PRNG, because the set of texts is too big (even for fairly short texts). But you'll never notice unless you're patient enough to wait for monkeys to write a Shakespeare play, which might take you a few universe lifetimes, and then cry foul when the allegedly random monkeys start repeating themselves from the beginning (at which point you notice that they were actually just robots using a PRNG). All a bigger period would do is put off that point, and with infinite (i.e no) period the point would never come, but if there's nothing else wrong with the PRNG then this is not much of a limitation. It's similar to secure hashes, which are used to e.g. give "unique" 256-bit tags to arbitrary bit strings, even though it's plain as day to everyone that the tags can't possibly be unique (by the pigeonhole principle). None of it matters in practice, as if this is the only problem with a secure hash, then the day you produce a counterexample we'll be busy dealing with the flying pig pest problem. -- Coffee2theorems 00:01, 10 August 2007 (UTC)

text: Excuse me, what the referenced post is saying is that lists of more than 2080 elements cannot be shuffled with MT19937 such that every permutation occurs at least once (probably less because some will occur more than once). While this is technically true, how does this have anything to do with a practical application? You might as well say that 5000 digits of Pi are not enough for approximating a circle. Sounds more like a thought experiment to me than a practical application. Aragorn2 (talk) 11:04, 10 February 2016 (UTC)
thread_title:  Period 

message: The article claims as an advantage that 3. It is faster than all but the most statistically unsound generators.  Well, the GSL timing data at http://www.csse.uwa.edu.au/programming/gsl-1.0/gsl-ref_16.html show at least two faster generators, neither of which have shown any statistical defect (or I haven't unearthed a reference to that effect).  So can someone please document the claim?  If not, it'll be removed in a week.
:According to Jackel (2002) Monte Carlo Methods in Finance, the Mersenne Twister, "is in fact faster than most other reliable pseudo-random number generators" and "no slower than any of the other pseudo-random generators". (p. 75) (perhaps a small exaggeration in a casual discussion) Measure for Measure 03:39, 11 November 2007 (UTC)
replies: text: The field of PRNG historically has some statistically poor generators, e.g. Linear congruential generator, so it is worth noting good generators' good statistical properties as an advantage. Cmcqueen1975 (talk) 02:08, 16 September 2014 (UTC)

text: My timing tests agree with yours in R2007a (7.4) but the MathWorks people think there's enough to MT that it's the MATLAB default for RAND as of this version. Still not available in RANDN. Patrick O'Leary 17:38, 4 October 2007 (UTC)
replies: text: Before you start removing stuff, let's discuss this a bit more. I gather from your timing table that the fastest three are, in order, taus, gfsr4 and mt19937. I take it mt19937 is this one. My question: do taus and gfsr4 pass all the same tests that mt19937 passes? If so, which tests have you applied? Did you apply any tests that some algorithms pass, but others fail? Can you provide a reliable source to back up your claims? 82.139.85.143 04:13, 14 October 2007 (UTC)
replies: text: http://www.iro.umontreal.ca/~lecuyer/myftp/papers/testu01.pdf reports tests for a number of other generators of this ilk.  See table I, starting at about page 28.  A few of these are faster than MT19937, and all report comparable results.  Take care to note that the cut-off for failure is extremely small in these tests.  (To paraphrase Linus Torvalds:  anyone who thinks a generator that fails a statistical test at the 1.0e-10 level is 'statistically unsound' may well be smoking crack ;-/).  Which is to say that the comments from Jackel, quoted by Measure for Measure above, are a better reflection of reality.  mdf (talk) 19:05, 19 November 2007 (UTC)

text: To mdf: What exactly do you mean with "no efficient 'stepping' ability"?--SiriusB 09:56, 14 November 2007 (UTC)
replies: text: To jump ahead so-and-so many states, without actually having to compute every intermediate state.  For F2 linear generators (like MT19937), this amounts to a simple matrix multiply, and the matrix can be computed quickly in a small amount of space, even for extremely large steps.  L'Ecuyer mentioned, in a few of his many papers, the problem with MT19937 having such a huge state makes the stepping issue hopeless (consider 19937-sized matrices, and O(n^3) algorithms).  However, when trying to relocate them to answer your question, I immediately came across Efficient Jump Ahead for F2-linear Random Number Generators, in which Haramoto, Matsumoto, Nishimura and L'Ecuyer effectively solve the MT19937 stepping problem.  mdf (talk) 19:05, 19 November 2007 (UTC)
thread_title:  Dubious advantages 

message: Here is a start on a list of examples of users of the Mersenne twister. When it gets to be a decent size it can go in the article. Kaldosh 09:32, 25 September 2007 (UTC)
thread_title:  Examples of users 

message: This is the current pseudocode in the article:
 // Create a length 624 array to store the state of the generator
 var int[0..623] MT
 var int y
 // Initialise the generator from a seed
 function initialiseGenerator ( 32-bit int seed ) {
     MT[0] := seed
     for i from 1 to 623 { // loop over each other element
         MT[i] := last_32bits_of(1812433253 * (MT[i-1] bitwise_xor right_shift_by_30_bits(MT[i-1])) + i)
     }
 }
 // Generate an array of 624 untempered numbers
 function generateNumbers() {
     for i from 0 to 623 {
         y := 32nd_bit_of(MT[i]) + last_31bits_of(MT[(i+1)%624])
         if y even {
             MT[i] := MT[(i + 397) % 624] bitwise xor (right_shift_by_1_bit(y))
         } else if y odd {
             MT[i] := MT[(i + 397) % 624] bitwise_xor (right_shift_by_1_bit(y)) bitwise_xor (2567483615) // 0x9908b0df
         }
     }
 }
 
 // Extract a tempered pseudorandom number based on the i-th value
 // generateNumbers() will have to be called again once the array of 624 numbers is exhausted
 function extractNumber(int i) {
     y := MT[i]
     y := y bitwise_xor (right_shift_by_11_bits(y))
     y := y bitwise_xor (left_shift_by_7_bits(y) bitwise_and (2636928640)) // 0x9d2c5680
     y := y bitwise_xor (left_shift_by_15_bits(y) bitwise_and (4022730752)) // 0xefc60000
     y := y bitwise_xor (right_shift_by_18_bits(y))
     return y
 }
The definition of pseudocode is: a compact and informal high-level description of a computer programming algorithm that uses the structural conventions of programming languages, but omits detailed subroutines, variable declarations or language-specific syntax. The programming language is augmented with natural language descriptions of the details, where convenient, or with compact mathematical notation. Well, this code is indeed not language-specific, but it is not compact and not informal. It is much bigger and less readible than the equivalents in most languages ("right_shift_by_11_bits" and then assuming % for modulo without explanation???),  Since the majority of users of such code are probably going to be C/C++ or FORTRAN users, I propose that it is converted into working C code:
// Create a length 624 array to store the state of the generator
// Most numbers are unsigned 32-bit integers
unsigned long int MT[624];
unsigned long int y;
int current_idx; // points to the current MT output number
// Generate an array of 624 [0..623] untempered numbers
void MTgenerateNumbers() {
  int i;
  for (i = 0; i <= 623; ++i) {
    y = ((MT[i] & 0x8000000) >> 31) // take 32nd bit
      + ( MT[(i+1) % 624] & 0x8fffffff); // AND with last 31 bits
    if (y & 1)
      // y even
      MT[i] = MT[(i + 397) % 624] ^ (y >> 1);
    else
      // y odd
      MT[i] = MT[(i + 397) % 624] ^ (y >> 1) ^ 2567483615ul; // 0x9908b0df; ul indicates unsigned long in C
  }
  current_idx = 0;
}
// Procedure to initialise the generator from a 32-bit seed
void MTinitialise(long unsigned int seed) {
  int i;
  MT[0] = seed;
  for (i = 1; i <= 623; ++i) // loop over remaining elements
    // & is a binary AND, ^ is a binary XOR, and >> a bit shift
    MT[i] = 0xffffffff & (1812433253 * (MT[i-1] ^ (MT[i-1] >> 30)) + i);
  MTgenerateNumbers();
}
 
// Extract the next tempered pseudorandom number
unsigned long int MTrandom() {
  // call generateNumbers() again if the array of 624 numbers is exhausted
  if (current_idx >= 624)
    MTgenerateNumbers();
  y = MT[current_idx];
  y = y ^ (y >> 11);
  y = y ^ ((y << 7) & 2636928640ul); // 0x9d2c5680
  y = y ^ ((y << 15) & 4022730752ul); // 0xefc60000
  y = y ^ (y >> 18);
  ++current_idx; // increment index
  return y;
}
Testing it with seed=1 gives this for the first few numbers:
  0 2773488264
  1 3990704388
  2 3757302560
  3 1411641254
  4 2593950992
  5  307370599
  6 2147185445
If that is not correct, then the pseudocode might be ambiguous. For example it is not clear to me whether 32nd_bit_of(MT[i]) means (MT[i] >> 31) or (MT[i] & 0x8000000).
Han-Kwang (t) 01:07, 21 November 2007 (UTC)
replies: text: Ambiguity is bad, and should be fixed.  I have no problem with working C/C++ code, though this may encourage optimization, and complaints about "Wikipedia sucks because it doesn't compile with BlazerSnort++ 6.1!".  Test-vectors is indeed a good idea, but this brings in "original research" and "howto" issues.  If that is moot, then it would be good to give the above, plus for states 624 - 630.  mdf (talk) 02:20, 21 November 2007 (UTC)
replies: text: It seems that there are variations on the initialization routine; e.g. this reference implementation produces different numbers when seeded with 1. I don't want to put in a piece of compilable C code unless I'm really sure that it is correct. A few comments above, there is a C snippet which might be better as an example. Unfortunately, it is incomplete: what are MATRIX_A, UPPER_MASK, LOWER_MASK, N? How is the mt array initialized? Han-Kwang (t) 19:20, 25 November 2007 (UTC)
thread_title:  Pseudocode 

message: All right. While I feel, that a link per programming language is ok, I also think that we should get some sort of order or hierarchy into that list. I suggest an alphabetical order. Opinions? --Gulliveig (talk) 14:22, 25 November 2007 (UTC)
thread_title: Implementation Links

message: The section about SFMT compares it to WELL in terms of speed... I found some information on http://www.iro.umontreal.ca/~panneton/WELLRNG.html - in the PDF it says that WELL stands for a family of "Well Equidistributed Long-period Linear” random number generators. Also, it is not clear to me why it is relevant in the discussion of SFMT, and not mentioned earlier. Are WELL generators significant enough to be mentioned at all? --Cynebeald (talk) 08:23, 17 January 2008 (UTC)
replies: text: Moreover, what does "v-bit accuracy" mean? It cannot be expected by the reader to guess (or even know) what a v-bit is and how it is related to random number generators.--SiriusB (talk) 14:16, 31 March 2008 (UTC)

text: WELL is developed in 2006(5?). It has beter equidistribution property than MT and has longer period than MT. WELL is a competitor of SFMT as a successor to MT.  —Preceding unsigned comment added by 133.41.90.32 (talk) 03:14, 29 September 2008 (UTC)
thread_title:  What is WELL? 

message: I'm nominating this page for the greatest understatement in all of Wikipedia award, more specifically for this statement:
:"most applications do not require 219937 unique combinations (219937 is approximately 4.315425 × 106001)."
Suppose I turn every elementary particle in the visible universe into a computer that produces 109 combinations a second, and I let all those computers run for the time that has elapsed since the Big Bang. Call the number of combinations all of them have now produced N1. Next, take N1 computers producing N1 combinations per second, and let those run for the same time. Call their total output in number of combinations N2. Under the same conditions let N2 computers turn out N2 combinations per second to generate N3 combinations during the age of the universe upto now, and let N3 computers do N3 combinations per second to get to N4, on the same way go from N4 to N5 and from N5 to N6. Then N6 is still much smaller than 106001... - Andre Engels (talk) 15:43, 3 October 2008 (UTC)
replies: text: I agree completely, that statement seemed really silly and I went into the talk section to say basically the same thing you've said.  I don't know why nobody ever wants to make definitive statements.  It is true to say "no application will ever require 219937 unique combinations", so why not just say it?  —Preceding unsigned comment added by 204.176.49.46 (talk) 21:03, 1 June 2009 (UTC)
replies: text:  People make statements like this about random number generators all the time.  In my opinion, such statements are worse than useless.  The number of particles in the universe has no relation to the quality of a random number generator, at least, not in the sense implied by these statements.  Only with relatively old or weak generators is exhausting the sequence an issue.  With modern generators, the main issue with period is the implications that the period has on output quality. Statements in this context discussing the number of particles in the universe or similar quantities mislead people into thinking that this is a pertinent topic. ATBS 11:53, 9 December 2009 (UTC)
replies: text: I moved the comparison to a footnote and removed the silliness.--agr (talk) 15:05, 9 December 2009 (UTC)
thread_title:  Understatement 

message: The article says that MT doesn't pass every test in TestU01 (just: most of them). However,  suggests that MT passes every test is TestU01, see Table 2 on Page 12. Or am I just interpreting something wrong in the linked paper...?  —Preceding unsigned comment added by 84.2.158.207 (talk) 11:55, 11 January 2010 (UTC)
thread_title:  Doesn't it pass all tests in TestU01? 

message: One of the comments says, "loop over each other element" which to me means skip over every other element, but that's not what the code appears to do (It appears to iterate over every element). Qutorial (talk) 19:35, 26 December 2010 (UTC)
replies: text: Done.  — Preceding unsigned comment added by 76.111.160.24 (talk) 20:35, 16 December 2014 (UTC)
thread_title: Pseudo code clarification

message: One issue with the current pseudo code is that it doesn't adequately explain that right shifts should shift in zeroes rather than performing the more common sign-extension. In C/C++ this is accomplished by making the various int variables unsigned. However, if someone naïvely implements based on the current pseudo-code, they will (probably) get answers inconsistent with the reference specification (http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/CODES/mt19937ar.c).
128.149.93.234 (talk) 20:48, 22 August 2011 (UTC)
thread_title:  Pseudocode (again) 

message: I changed:
         int y := 32nd bit of(MT[i]) + last 31 bits of(MT[(i+1) mod 624])
 to
         int y := (MT[i] & 0x80000000) + (MT[(i+1) mod 624] & 0x7fffffff)
because the description, although word-oriented, is confusing, and basically wrong.  The 32nd bit of a number is ambiguous because the bit numbering scheme isn't stated, and what you want is that bit in its shifted state.  Otherwise, the "32nd bit" is 0 or 1, which is not what's wanted.  The change was reverted, and I'm not going to change it back, at least not yet, but I doubt anyone is going to be able to code it properly from the current wording.  I couldn't.  My wording might be C-oriented, but at least it's accurate. 
209.66.98.94 (talk) 21:50, 31 October 2012 (UTC)
replies: text: Hmmmm.... could we do both?  I'm thinking of your change being the pseudocode and the old pseudocode being a comment.  (I don't disagree with anything you said, except that I found the wordy version to be clear enough given the context and my background.  I also found your version to be equally clear, which probably means that I'm a poor judge of pseudocode that's intended to be read by less experienced coders.)  GaramondLethe 22:33, 31 October 2012 (UTC)

text: Both would be fine, in my opinion.
209.66.98.94 (talk) 04:23, 2 November 2012 (UTC)
replies: text: Take a look and see what you think.  I'm not sure there's a good way of guiding a reader who doesn't understand bitmasks through this algorithm.  Feel free to improve on this.  GaramondLethe 06:22, 2 November 2012 (UTC)
thread_title:  Pseudo-Code 

message: The Lua implementation listed in the article is written in C. You can use the function in Lua though. SharkD  Talk  22:53, 8 September 2013 (UTC)
thread_title:  Lua 

message: On the wikipedia, algorithm descriptions are NEVER given in English - e.g. an actual explanation - they are given as highly mathmatical proofs, which are unreadable to all except qualified mathematicians, i.e. almost nobody.  I'd change it, but invariably such changes are reverted.  There is something broken about wikipedia culture in this regard.  31.48.59.85 (talk) 08:06, 26 July 2014 (UTC)
thread_title: Appalling algorithm description

message: The statement "(a period above 2512 is enough for any application)" in Mersenne twister#Disadvanages looks like a dubious claim to me. Monte Carlo methods often require RNG's with a very long period; also, the Fisher-Yates shuffle requires very long periods for shuffling all but the smallest of sets - see this for reasoning. -- 2001:470:BB6F:0:DDB4:997F:D54D:AE09 (talk) 02:53, 27 August 2014 (UTC)
replies: text: The statement is valid, see e.g. Numerical Recipes, §7.1: "Avoid using generators with period > 10100".  The discussion that you cited, from the Fisher-Yates Shuffle, just argues that 262 ≐ 1017 is too small, which is indeed true.  That is a long way, though, from 10100 ≐ 2333.   86.181.32.91 (talk) 15:08, 27 August 2014 (UTC)
replies: text: 2 ^ 512 is a huge number and there is no way any application will ever generate or need that many numbers.  My source is Applied Cryptography, which talks about a 512 bit key being large enough for any imaginable situation.  Samboy (talk) 12:01, 28 August 2014 (UTC)
replies: text: I agree.  I restored the article, and included the reference to Numerical Recipes.  If you have the full reference to Applied Cryptography (e.g. section or page number), perhaps it is worth adding?   86.181.32.91 (talk) 15:58, 28 August 2014 (UTC)
replies: text: I lost my copy of Applied Cryptography years ago when I loaned it to an ex-roomate, so I can’t be more specific.   However, Schneier goes down a similar path in this 1999 essay, where he states “we cannot even imagine a world where 256-bit brute force searches are possible” Samboy (talk) 17:42, 28 August 2014 (UTC)
replies: text: My reading of that link is that it is referring to cryptographically-secure keys for public-key cryptography.  That is relevant for a CSPRNG, but not for a general PRNG, which is what the Mersenne Twister aims to be.   86.181.32.91 (talk) 18:41, 28 August 2014 (UTC)
thread_title:  Statement about periodicity 

message: The claim looks atrociously dubious, to me, too.
2512 is indeed quite a big number, but it's not combinatorially big. What I mean by that is the following simple argument: how many permutations of 150 distinct elements are there? A little more than 2872. Will I obtain one of those permutations uniformly at random by plugging a PRNG with period 2512 into a Fisher-Yates-like shuffle? Nope: quite a lot of permutations will never happen; only a subset of those fitting into the period will; that is not a uniform shuffle. By the same pigeonhole principle, we can't get uniform numbers in [1..100] from a generator with period 10, no matter how hard we try. There's just not enough entropy available.
And what if I wanted to shuffle 2000 items, rather than just 150? By the way, a Mahjong deck consists of 136 tiles; with certain tiles considered indistinguishable, that gives around 2763 shuffles possible. So for an internet server of that game, a 2512-period PRNG is practically not good enough: literally most shuffles, while having non-zero probability of happening in an IRL game, would be never dealt on the server.
Obviously, this happens because the factorial function (giving the number of permutations) grows even faster than exponentially (which is already damn fast). In many computations, one will need to generate samples from exponentially big spaces (random trees of height n would be an example). In such computations, period of mere 2512 might not give enough "resolution" to pick samples densely enough.
--77.91.170.13 (talk) 01:19, 2 February 2016 (UTC)
thread_title:  Agreed 

message: I also have an objection regarding the quality of "Numerical Recipes" citation. It seems I can't verify it. The whole §7.1 contains neither the "Avoid using generators with period > 10100", neither the article quote, nor any other recommendation to avoid big periods, as I read it. The closest passage I find is "If you are generating more than 100,000,000  random numbers in a single calculation... [use ran2]" — but its nowhere near the claim in the article allegedly supported by the citation. I presume that it's a misunderstanding, and not an intentional citation abuse.
The citation, as well as the claim itself, is going to be removed. Anyway, it brings not much value into the article besides fuelling talkpage debates like this one and several others above it.
--77.91.170.13 (talk) 01:19, 2 February 2016 (UTC)
thread_title:  Can't verify §7.1 citation 

message: Good job. A really good article. 79.19.208.168 (talk) 17:15, 6 September 2014 (UTC)
thread_title:  This article is very good 

message: in line 10 of the psuedocode, the value 1812433253 (0x6c078965) appears. There's nothing in the algorithmic detail explaining where this value comes from
173.48.10.131 (talk) 16:13, 22 October 2014 (UTC)
replies: text: It's there because whoever "contributed" that pseudocode were plagiarising a paper that in turn didn't explain that the number came from Matsumoto et al's Cryptographic Mersenne Twister and Fubuki Stream/Block Cipher, 2005 (Link); the latter chose it for no special reason except that it should be a good multiplier for a Linear Congruential Generator. Cryptarch (talk) 04:36, 20 March 2015 (UTC)
thread_title:  algorithmic detail vs. psuedocode 

message: There is this claim in the lead. While it has good uptake I would suspect the simple linear congruential generator would have higher use. There are the standard one used in Java and older C implementations, .NET. --Salix alba (talk): 07:58, 12 November 2014 (UTC)
thread_title:  By far, the most widely used PRNG? 

message: The sections on Algorithmic Detail and Pseudocode are very similar to Section II in Tian, Xiang, and Khaled Benkrid, Mersenne Twister random number generation on FPGA, CPU and GPU, Adaptive Hardware and Systems, 2009. 
(Link to paper) I don't think this is an example of fair use. Cryptarch (talk) 04:26, 20 March 2015 (UTC)
replies: text: For anyone trying to investigate/resolve this complaint, this is the new link to the paper. I will attempt to digest the explanation in the paper and rewrite it. At the very least, I have begun rewriting the pseudocode based on extracting the commonalities in multiple different real implementations. Fizbin7 (talk) 11:39, 19 July 2015 (UTC)

text: I believe my latest edit fixes these plagiarism issues. Fizbin7 (talk) 21:32, 19 July 2015 (UTC)
replies: text: Though looking through the history, I see now that this is more likely a case of the paper author pulling from wikipedia than the other way around - the pseudocode used in the paper appeared on wikipedia first. I still think my new pseudocode is an improvement - covering more cases - but there was never a need to rewrite it on plagiarism grounds. 96.235.144.166 (talk) 12:47, 20 July 2015 (UTC)
thread_title:  Plagiarism 

message: I put my edit at: Mersenne_Twister/Sandbox User:Comp.arch/Mersenne Twister.
I hope whoever is editing concurrently sees my last edit and didn't overwrite that one.. comp.arch (talk) 14:00, 10 June 2016 (UTC)
thread_title:  Can't edit page because of Wikipeda server bogus "old page" edit conflict 

message: According to dash, the preferred use seems to be an em dash. Even if the two uses were equally preferred, there is no reason to change from em dash, unless there is a consensus of editors. Additionally, the title of the web page for Julia has an em dash, and that cannot be changed under any circumstances.
As for Apache Commons, MT is part of that; specifying a subpart breaks consistency with the other citations and also might add confusion (e.g. it is unlinked). As for the minus sign, this should be consistent throughout the article.
86.178.35.99 (talk) 18:20, 17 June 2016 (UTC)
thread_title:  dash, Apache Commons, minus sign 

message: I note that the python 32-bit implementation as given does not limit the seed to a 32bit int despite using hardcoded 32 bit MT values.
In python this allows the seed to accept an int of virtually unlimited size. The remainder appears correct and all subsequent values are trimmed to 32 bits with the masking in twist() and indeed in the remainder of __init__, thus: self.mt[i] = _int32(...
Perhaps it is useful.  But, I think it is an oversight maybe.
Another minor comment is that the seed function comment says 'Initialize the index to 0' then immediately sets it to a hard coded constant very unlike 0. Updated to correct and explain.
Existing code:
    class MT19937:
        def __init__(self, seed):
            # Initialize the index to 0
            self.index = 624
    etc.
Suggested replacement:
    class MT19937:
        def __init__(self, seed):
            # Make it clear the seed is going to be a 32-bit int
            seed = _int32(seed)
            # Initialize the index to 'n' as used by the 32-bit values (change it to 312 for 64-bit implementations).
            # This ensures an immediate twist() on the first extract() call.
            self.index = 624
        etc.
edits: many
Epoch-1 (talk) 07:22, 31 May 2017 (UTC)
thread_title:  Python Sample Code accepts any size seeds, despite using hardcoded 32-bit parameters 

message: The article was previously written in a way that allowed non-technical readers to understand the first few sections. The first three sections were these: "Adoption in software systems", "Advantages", "Disadvantages". Following those sections were sections that supplied technical details. 
That structure made it easy for non-technical readers to understand the wide usage of the Mersenne Twister, why the Mersenne Twister is important, and what possible shortcomings are. The structure was also in conformance with MOS:COMPSCI. MOS:COMPSCI states, in particular, that "It can be helpful to have a section on motivation or applications in the informal introduction…".
The article was revised so that it began with these sections: "k-distribution", "Algorithmic detail". Those sections are highly technical, and will only be understandable to people who have relevant technical background and are willing to put in significant time and effort to comprehend them. Non-technical readers will get turned off: they will generally get much less benefit from the article. Even some technical readers will get less benefit, because they will skim over the first two sections, and then read little more (that is what I would probably do). The revised structure also does not adhere to MOS:COMPSCI guidelines, which state that "A general approach is to start simple, then move toward more formal and technical statements as the article proceeds".
I have restored the original structure of the article.  FlagrantUsername (talk) 08:57, 16 November 2017 (UTC)
replies: text: I agree with you on the article structure. I have also followed you in removing code from the article. I think snippets of code should generally only appear in articles in the context of a discussion or explanation.--Pontificalibus (talk) 16:06, 20 November 2017 (UTC)
thread_title:  Structure of the article 

message: In Section 6.1 ("Initialization"), the symbol "×" is used in the mathematical formula without precisions about what operation is denotes (unlike in previous formulas where other symbols like "⊕" are explained). Looking at the pseudocode it seems that here "×" means integer multiplication followed by truncation to the lowest w bits. If this is the case it would be nice to mention it right below the formula, just like it is done in other formulas. --Cédric VAN ROMPAY (talk) 12:57, 15 November 2018 (UTC)
thread_title:  Missing description of operation 

message: I have removed link to K-distribution which is incorrect, replacing it with a pointer to the Mersenne_Twister#k-distribution paragraph in this page jw (talk) 13:02, 24 September 2019 (UTC)
replies: text:  The article doesnt define the f variable whatsoever, but its used in the pseudocode.  The upper_mask variable is poorly explained, even in the psuedocode.  — Preceding unsigned comment added by 50.34.40.6 (talk) 04:14, 14 July 2022 (UTC)
thread_title:  /* k-distribution */ 

message: this page is impossible for a layperson (me) understand. 67.85.59.145 (talk) 04:35, 4 December 2019 (UTC)
thread_title:  Impossible to understand 

message: Using a seed of 0, the twister would forever output a value of 0, unlike if you use the actual pseudocode.
Georgariou (talk) 20:37, 22 January 2021 (UTC)
thread_title:  Python pseudocode doesn't work with a seed of 0 

message: Both F and \mathbb{F} seem to be used in the same contexts; I suspect some of those are incorrect and need to be changed to the other? -- Beland (talk) 19:32, 17 March 2021 (UTC)
thread_title:  F vs. 𝔽 

message: Im not going to say this is "too complicated" to understand, because it isnt. It IS poorly written and poorly explained. The criticisms pile up to the point I dont even want to list them anymore.  — Preceding unsigned comment added by 50.34.40.6 (talk) 03:44, 14 July 2022 (UTC)
thread_title:  Poor explanations 

message: Hola Señores feudales de Wikipedia,
Este artículo es indescifrable. Si vuestro propósito era criptografiarlo, lo habéis conseguido. Ni Alan Turing sería capaz de decodificarlo. Espero que alguien ahí fuera tenga la empatía suficiente para hacer este artículo más accesible a dummies como yo.
Darío =).
P.D.: Sigo siendo fan de Wikipedia. Me salvó muchas veces en mi carrera. XoXo (L). 81.172.60.141 (talk) 19:53, 13 March 2023 (UTC)
thread_title:  Re-escribir el artículo para dummies como yo. 

message: In the very first sentence:
 "The Mersenne Twister is a general-purpose pseudorandom number generator (PRNG) developed in 1997 by Makoto Matsumoto [ja]"
the name link at the end, "Makoto Matsumoto", if you click on it leads you to a page for Tomohiro Matsu. This is a different person, this link seems to be wrong. SammyAsher (talk) 06:19, 17 April 2023 (UTC)
thread_title:  Hyperlink goes to wrong person