similar to: Extreme bunching of random values from runif with Mersenne-Twister seed

Martin, Thanks for the helpful reply. Alas I had forgotten that (implied) unfavorable comparisons of *nix systems with Windows systems would likely draw irate (but always substantive) responses on the R-devel list -- poor phrasing on my part. :) Regardless, let me try to address some of the concerns related to the construction of the MRE itself and try to see if we can clean away the shrubbery

This is cross-posted from SO (https://stackoverflow.com/q/47079702/1414455), but I now feel that this needs someone from R-Devel to help understand why this is happening. We are facing a weird situation in our code when using R's [`runif`][1] and setting seed with `set.seed` with the `kind = NULL` option (which resolves, unless I am mistaken, to `kind = "default"`; the default being

>>>>> Tirthankar Chakravarty <tirthankar.lists at gmail.com> >>>>> on Fri, 3 Nov 2017 13:19:12 +0530 writes: > This is cross-posted from SO > (https://stackoverflow.com/q/47079702/1414455), but I now > feel that this needs someone from R-Devel to help > understand why this is happening. Why R-devel -- R-help would have been

The random numbers in a stream initialized with one seed should have about the desired distribution. You don't win by changing the seed all the time. Your seeds caused the first numbers of a bunch of streams to be about the same, but the second and subsequent entries in each stream do look uniformly distributed. You didn't say what your 'upstream process' was, but it is easy to

Another other generator is subject to the same problem with the same probabilitiy. > Filter(function(s){set.seed(s, kind="Knuth-TAOCP-2002");runif(1,17,26)>25.99}, 1:10000) [1] 280 415 826 1372 2224 2544 3270 3594 3809 4116 4236 5018 5692 7043 7212 7364 7747 9256 9491 9568 9886 Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Nov 3, 2017 at 10:31 AM, Tirthankar

Tirthankar, "random number generators" do not produce random numbers. Any given generator produces a fixed sequence of numbers that appear to meet various tests of randomness. By picking a seed you enter that sequence in a particular place and subsequent numbers in the sequence appear to be unrelated. There are no guarantees that if YOU pick a SET of seeds they won't produce

Bill, Appreciate the point that both you and Serguei are making, but the sequence in question is not a selected or filtered set. These are values as observed in a sequence from a mechanism described below. The probabilities required to generate this exact sequence in the wild seem staggering to me. T On Fri, Nov 3, 2017 at 11:27 PM, William Dunlap <wdunlap at tibco.com> wrote: >

Bill, I have clarified this on SO, and I will copy that clarification in here: "Sure, we tested them on other 8-digit numbers as well & we could not replicate. However, these are honest-to-goodness numbers generated by a non-adversarial system that has no conception of these numbers being used for anything other than a unique key for an entity -- these are not a specially constructed

> On 5 Nov 2017, at 15:17 , Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > On 04/11/2017 10:20 PM, Daniel Nordlund wrote: >> Tirthankar, >> "random number generators" do not produce random numbers. Any given >> generator produces a fixed sequence of numbers that appear to meet >> various tests of randomness. By picking a seed you enter

On 04/11/2017 10:20 PM, Daniel Nordlund wrote: > Tirthankar, > > "random number generators" do not produce random numbers. Any given > generator produces a fixed sequence of numbers that appear to meet > various tests of randomness. By picking a seed you enter that sequence > in a particular place and subsequent numbers in the sequence appear to > be unrelated.

Hi, It seems to me that the Mersenne-Twister PRNG can be initialised using one integer instead of 624 integers, since inside RNG.c code there's a function defined as MT_sgenrand(Int32). How do I actually set this seed within R? I've tried: > .Random.seed <- c(3, 1) > runif(1) Error in runif(1) : .Random.seed has wrong length In addition, is '3' actually the

I don't see evidence of a bug. There have been several versions of the MT; we may be using a different version than you are. Ours is the 1999/10/28 version; the web page you cite uses one from 2002. Perhaps the newer version fixes some problems, and then it would be worth considering a change. But changing the default RNG definitely introduces problems in reproducibility, so it's

I wonder how useful a (set of?) "time machine" functions which look up /infer things like this based on a date would be. Could ease the pain of changes generally, though not remove it completely. ~G On Wed, Aug 31, 2016 at 5:45 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote: > > > On 08/30/2016 06:29 PM, Duncan Murdoch wrote: > >> I don't see evidence of

On 30 August 2016 at 18:29, Duncan Murdoch wrote: | I don't see evidence of a bug. There have been several versions of the | MT; we may be using a different version than you are. Ours is the | 1999/10/28 version; the web page you cite uses one from 2002. | | Perhaps the newer version fixes some problems, and then it would be | worth considering a change. But changing the default RNG

On 08/30/2016 06:29 PM, Duncan Murdoch wrote: > I don't see evidence of a bug. There have been several versions of the > MT; we may be using a different version than you are. Ours is the > 1999/10/28 version; the web page you cite uses one from 2002. > > Perhaps the newer version fixes some problems, and then it would be > worth considering a change. But changing the

Whomever, I recently sent the "bug report" below toR-core at r-project.org and have just been asked to instead submit it to you. Although I am basically not an R user, I have installed version 3.3.1 and am also the author of a statistics program written in Visual Basic that contains a component which correctly implements the Mersenne Twister (MT) algorithm. I believe that it is

I have an ActiveRecord subclass that needs to generate a random (hard to guess) token for each record in its corresponding table. Currently I''m doing something like this: def before_create self[''token''] = random_value while self.class.find_by_token(self[''token'']) self[''token''] = random_value

Hi guys, I can''t find a clear answer to this: is it possible/correct to have several threads write to the same Starling queue at the "same time"? It doesn''t seem reliable according to my tests - but maybe I am doing something wrong. If I do: def test_starling FooWorker.asynch_foo_test(:my_id => ''foo'') temp = [] for i in 1..1000 temp

We are seeing this weird problem, it seems to happen at random periods throughout the day from a few minuets to a up to an hour. [Phone A] >--SIP--> [Asterisk] >--SIP--> [Phone B] Both phones are snom 360's. Asterisk is Stable 1.0.9 Pretty simple config, just a dial direct to each other like Dial(SIP/phoneA,30,t) Running Gentoo linux When we make a call during one of the problem

A couple of days ago a few messages indicated that something changed in the basic plot routine that made plot(*, type='l') slow for large data sets. Some people even reported crashes for very large data sets. As far as I remember, this was not reported as a formal bug. I am still not sure if this is a bug, so I report my findings here. First of all, I think I see a slowdown of the plot