Rewrote the PRNG using an xorshift* algorithm and moved the files from test/ to base/.

Rewrote the PRNG using an xorshift* algorithm and moved the files from test/ to base/.

Created a simple unit test for the new random number generator. (It mostly tests
that the generated numbers are consistent with the intended distribution, e.g. uniform.
It is not a comprehensive test of the quality of the random numbers.)

Several assertions in OveruseDetectorTest seem to depend on the exact sequence of random numbers. I updated those numbers to work with the new PRNG.

Compute the standard deviation of the expected result in TestReorderFilter instead of passing an uncertainty parameter.

BUG=webrtc:5177
Committed: https://crrev.com/84e78f9102dfbe9fc17aecd8d9d816042425a294
Cr-Commit-Position: refs/heads/master@{#10965}

[terelius, 2015-11-19 09:24:44]

Description was changed from

==========
Rewrote the PRNG using an xorshift* algorithm and moved the files from test/ to
base/.

Created a simple unit test for the new random number generator. (It mostly tests
that the generated numbers are consistent with the intended distribution, e.g.
uniform.
It is not a comprehensive test of the quality of the random numbers.)

Several assertions in OveruseDetector seem to depend on the exact sequence of
random numbers. I updated those numbers to work with the new PRNG.

Compute the standard deviation of the expected result in TestReorderFilter
instead of passing an uncertainty parameter.

BUG=webrtc:5177
==========

to

==========
Rewrote the PRNG using an xorshift* algorithm and moved the files from test/ to
base/.

Created a simple unit test for the new random number generator. (It mostly tests
that the generated numbers are consistent with the intended distribution, e.g.
uniform.
It is not a comprehensive test of the quality of the random numbers.)

Several assertions in OveruseDetectorTest seem to depend on the exact sequence
of random numbers. I updated those numbers to work with the new PRNG.

Compute the standard deviation of the expected result in TestReorderFilter
instead of passing an uncertainty parameter.

BUG=webrtc:5177
==========

[terelius, 2015-11-19 10:01:39]

terelius@webrtc.org changed reviewers:
+ mflodman@webrtc.org, pbos@webrtc.org, solenberg@webrtc.org, stefan@webrtc.org

[terelius, 2015-11-19 10:01:40]

Please have a look at this CL which improves the random number generator. Moving
the files to base/ gives us opportunities to use it in the rest of the code and
would allow us to get rid of rand() in some places.

Fredrik & Peter, we've discussed the random number generator before.

Stefan, could you check my changes of the EXPECT_EQs in remote_bitrate_estimator
in particular?

Magnus, is the move to base ok?

[the sun, 2015-11-20 09:38:51]

https://codereview.webrtc.org/1457023002/diff/80001/webrtc/base/random.h
File webrtc/base/random.h (right):

https://codereview.webrtc.org/1457023002/diff/80001/webrtc/base/random.h#newc...
webrtc/base/random.h:53: // TODO(solenberg): Random from histogram.
You can remove this TODO, or take over it. :)

https://codereview.webrtc.org/1457023002/diff/80001/webrtc/base/random.h#newc...
webrtc/base/random.h:62: RTC_DCHECK(state_ != 0x0ULL);
If the output *by definition* can never be zero, then we're lying about the
intervals for all the Rand() methods?

[terelius, 2015-11-20 10:32:29]

https://codereview.webrtc.org/1457023002/diff/80001/webrtc/base/random.h
File webrtc/base/random.h (right):

https://codereview.webrtc.org/1457023002/diff/80001/webrtc/base/random.h#newc...
webrtc/base/random.h:53: // TODO(solenberg): Random from histogram.
On 2015/11/20 09:38:50, the sun wrote:
> You can remove this TODO, or take over it. :)

Ok, removed it.

https://codereview.webrtc.org/1457023002/diff/80001/webrtc/base/random.h#newc...
webrtc/base/random.h:62: RTC_DCHECK(state_ != 0x0ULL);
On 2015/11/20 09:38:50, the sun wrote:
> If the output *by definition* can never be zero, then we're lying about the
> intervals for all the Rand() methods?

The 64-bit state can never be 0 but the integer functions truncate the state to
32-bits. Since all non-zero 64 bit numbers appear exactly once, there are
4294967295 states that get truncated to zero and 4294967296 states that get
truncated to each nonzero number. Thus the probability of generating a 0 is
(2^32-1)/(2^64-1) and the probability of each nonzero number is 2^32/(2^64-1).
These probabilities are very close to 2^32/2^64 which is what a true uniform
distribution should have.

The Rand<float> and Rand<double> compensate by subtracting one from NextOutput()
before dividing by 2^64-1. In Gaussian() we actually want a non-zero number.

[The Sun (google.com), 2015-11-20 11:37:18]

solenberg@google.com changed reviewers:
+ solenberg@google.com

[The Sun (google.com), 2015-11-20 11:37:18]

https://codereview.webrtc.org/1457023002/diff/80001/webrtc/base/random.h
File webrtc/base/random.h (right):

https://codereview.webrtc.org/1457023002/diff/80001/webrtc/base/random.h#newc...
webrtc/base/random.h:62: RTC_DCHECK(state_ != 0x0ULL);
On 2015/11/20 10:32:29, terelius wrote:
> On 2015/11/20 09:38:50, the sun wrote:
> > If the output *by definition* can never be zero, then we're lying about the
> > intervals for all the Rand() methods?
> 
> The 64-bit state can never be 0 but the integer functions truncate the state
to
> 32-bits. Since all non-zero 64 bit numbers appear exactly once, there are
> 4294967295 states that get truncated to zero and 4294967296 states that get
> truncated to each nonzero number. Thus the probability of generating a 0 is
> (2^32-1)/(2^64-1) and the probability of each nonzero number is 2^32/(2^64-1).
> These probabilities are very close to 2^32/2^64 which is what a true uniform
> distribution should have.

Ah, I should have read the implementation; thanks for explaining!

> The Rand<float> and Rand<double> compensate by subtracting one from
NextOutput()
> before dividing by 2^64-1. In Gaussian() we actually want a non-zero number.

[pbos-webrtc, 2015-11-20 12:51:57]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h
File webrtc/base/random.h (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h#new...
webrtc/base/random.h:29: T Rand() {
Do we need this generic template version or is support for the specialized
versions enough?

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h#new...
webrtc/base/random.h:35: return static_cast<T>(NextOutput());
I believe this is undefined value/implementation may raise signal (almost UB)
for uint32_t->int32_t for half the values.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h#new...
webrtc/base/random.h:55: uint64_t NextOutput() {
Move implementation to .cc

[the sun, 2015-11-25 10:12:38]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h
File webrtc/base/random.h (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h#new...
webrtc/base/random.h:29: T Rand() {
On 2015/11/20 12:51:57, pbos-webrtc wrote:
> Do we need this generic template version or is support for the specialized
> versions enough?

It is quite useful; often you need to get a random value for an integer range.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
File webrtc/base/random_unittest.cc (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:17: #include "webrtc/base/checks.h"
Not needed?

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:25: assert(n > 0);
ASSERT_GT()

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:33: template <typename T>
Can you describe the test method, or provide a link?

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:42: assert(upper_limit >
std::numeric_limits<T>::max() / 2);
ASSERT_GT()

...and other assert()s below.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:65: UniformBucketTest<signed char>(64, 640000,
&prng);
Are these number empiric or from some calculation?

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:288: // sample is in the interval [n-0.5, n-0.5].
That's an awfully small interval.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/modules/remote_bi...
File webrtc/modules/remote_bitrate_estimator/test/bwe_test_framework_unittest.cc
(right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/modules/remote_bi...
webrtc/modules/remote_bitrate_estimator/test/bwe_test_framework_unittest.cc:538:
// The expected number of swaps we perform is PacketCount - 1,
expected->maxiumum

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/modules/remote_bi...
webrtc/modules/remote_bitrate_estimator/test/bwe_test_framework_unittest.cc:542:
// pair is p * (1-p). Since there are (kPacketCount - 1) independent pairs,
super nit: "1-p" -> "1 - p"

Also, if would care to give me a short math lesson, that'd be appreciated! :)

[pbos-webrtc, 2015-11-25 21:16:16]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h
File webrtc/base/random.h (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h#new...
webrtc/base/random.h:35: return static_cast<T>(NextOutput());
On 2015/11/20 12:51:57, pbos-webrtc wrote:
> I believe this is undefined value/implementation may raise signal (almost UB)
> for uint32_t->int32_t for half the values.

We might accept this so long as ubsan doesn't start barking on it. It's not
undefined behaviour, but it may raise a trap which would effectively crash the
program. I don't think we run on any such platforms.

[terelius, 2015-11-27 10:35:24]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
File webrtc/base/random_unittest.cc (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:17: #include "webrtc/base/checks.h"
On 2015/11/25 10:12:37, the sun wrote:
> Not needed?

Done.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:25: assert(n > 0);
On 2015/11/25 10:12:37, the sun wrote:
> ASSERT_GT()

ASSERT requires a void function. In this case I think it is perfectly reasonable
to kill the test upon triggering the assertion since the assertion is a sanity
check on the test case itself. The assertion essentially says that the number of
buckets needs to be positive, or equivalently that we need space for at least
one element in a vector to store the result.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:33: template <typename T>
On 2015/11/25 10:12:37, the sun wrote:
> Can you describe the test method, or provide a link?

Done. This is not some sophisticated test for randomness.
It merely samples some numbers, divides them into buckets
(in this case based on the remainder when dividing by
the number of buckets) and verifies that all buckets receive
approximately the same number of elements.

I've added a comment to this effect.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:42: assert(upper_limit >
std::numeric_limits<T>::max() / 2);
On 2015/11/25 10:12:38, the sun wrote:
> ASSERT_GT()
> 
> ...and other assert()s below.

Done.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:65: UniformBucketTest<signed char>(64, 640000,
&prng);
On 2015/11/25 10:12:37, the sun wrote:
> Are these number empiric or from some calculation?

Neither. It is just a call that says "Generate 640000 random numbers, distribute
them evenly in 64 buckets and check that each bucket has approximately the same
number of elements in them." I vary the number of buckets to test powers of two,
odd numbers close to powers of two and odd numbers far from powers of two.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:288: // sample is in the interval [n-0.5, n-0.5].
On 2015/11/25 10:12:37, the sun wrote:
> That's an awfully small interval.

In this test, we draw a real number x from a gaussian distribution and round it
to the nearest integer n.

We want to know the probability of getting a particular integer n. If x is
rounded to n, then x must be in the interval [n-0.5, n+0.5). The probability
that x is in [a, b) is the integral from a to b of the probability density
function p(x). Since the interval is fairly small, we can estimate the integral
using a small number of points. The previous version of this test (located in
remote_bitrate_estimator) used only one point. I increased it to 3 points to get
a more accurate estimate, but the difference is likely small for the parameters
we are testing.

[the sun, 2015-11-27 11:02:10]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
File webrtc/base/random_unittest.cc (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:25: assert(n > 0);
On 2015/11/27 10:35:24, terelius wrote:
> On 2015/11/25 10:12:37, the sun wrote:
> > ASSERT_GT()
> 
> ASSERT requires a void function. In this case I think it is perfectly
reasonable
> to kill the test upon triggering the assertion since the assertion is a sanity
> check on the test case itself. The assertion essentially says that the number
of
> buckets needs to be positive, or equivalently that we need space for at least
> one element in a vector to store the result.

Don't use stdlib assert(). gtest's ASSERT_nn or EXPECT_nn should work fine here.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:288: // sample is in the interval [n-0.5, n-0.5].
On 2015/11/27 10:35:24, terelius wrote:
> On 2015/11/25 10:12:37, the sun wrote:
> > That's an awfully small interval.
> 
> In this test, we draw a real number x from a gaussian distribution and round
it
> to the nearest integer n.
> 
> We want to know the probability of getting a particular integer n. If x is
> rounded to n, then x must be in the interval [n-0.5, n+0.5). The probability
> that x is in [a, b) is the integral from a to b of the probability density
> function p(x). Since the interval is fairly small, we can estimate the
integral
> using a small number of points. The previous version of this test (located in
> remote_bitrate_estimator) used only one point. I increased it to 3 points to
get
> a more accurate estimate, but the difference is likely small for the
parameters
> we are testing.
> 

But isn't the comment wrong? "[n-0.5, n-0.5]"

[pbos-webrtc, 2015-11-27 11:06:28]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
File webrtc/base/random_unittest.cc (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:25: assert(n > 0);
On 2015/11/27 11:02:10, the sun wrote:
> On 2015/11/27 10:35:24, terelius wrote:
> > On 2015/11/25 10:12:37, the sun wrote:
> > > ASSERT_GT()
> > 
> > ASSERT requires a void function. In this case I think it is perfectly
> reasonable
> > to kill the test upon triggering the assertion since the assertion is a
sanity
> > check on the test case itself. The assertion essentially says that the
number
> of
> > buckets needs to be positive, or equivalently that we need space for at
least
> > one element in a vector to store the result.
> 
> Don't use stdlib assert(). gtest's ASSERT_nn or EXPECT_nn should work fine
here.

Feel free to use RTC_(D)CHECK_GT if all else fails. :)

[terelius, 2015-11-27 11:31:23]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h
File webrtc/base/random.h (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h#new...
webrtc/base/random.h:29: T Rand() {
On 2015/11/25 10:12:37, the sun wrote:
> On 2015/11/20 12:51:57, pbos-webrtc wrote:
> > Do we need this generic template version or is support for the specialized
> > versions enough?
> 
> It is quite useful; often you need to get a random value for an integer range.

I think pbos is suggesting not having the generic rand<T>(), but instead adding
more specialized versions with rand<int>(), rand<unsigned>(), rand<short>(),
etc. The effect would be the same, but the code would be longer.

I prefer rand<T>() unless the specializations somehow solves the
implementation-defined behavior of the cast.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h#new...
webrtc/base/random.h:35: return static_cast<T>(NextOutput());
On 2015/11/25 21:16:16, pbos-webrtc wrote:
> On 2015/11/20 12:51:57, pbos-webrtc wrote:
> > I believe this is undefined value/implementation may raise signal (almost
UB)
> > for uint32_t->int32_t for half the values.
> 
> We might accept this so long as ubsan doesn't start barking on it. It's not
> undefined behaviour, but it may raise a trap which would effectively crash the
> program. I don't think we run on any such platforms.

The best solution I've been able to come up with, is 
uint32_t r = NextOutput();
return *((T*) &r);
which forces a uniform bit pattern into a T. However, trying to read the
resulting T is probably undefined since the T could have padding bits which the
processor/compiler might expect to be e.g. zero. I don't know of any such
machines.

I'm pretty sure we don't run on machines where a plain static_cast from unsigned
to signed causes a trap, since there are numerous of those casts in the code
base already.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random.h#new...
webrtc/base/random.h:55: uint64_t NextOutput() {
On 2015/11/20 12:51:57, pbos-webrtc wrote:
> Move implementation to .cc

I actually prefer to have this inlined since the body should take ~10 cycles.
The cost of an extra function call would be non-negligible I think.

[terelius, 2015-11-27 11:46:08]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
File webrtc/base/random_unittest.cc (right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:25: assert(n > 0);
On 2015/11/27 11:02:10, the sun wrote:
> On 2015/11/27 10:35:24, terelius wrote:
> > On 2015/11/25 10:12:37, the sun wrote:
> > > ASSERT_GT()
> > 
> > ASSERT requires a void function. In this case I think it is perfectly
> reasonable
> > to kill the test upon triggering the assertion since the assertion is a
sanity
> > check on the test case itself. The assertion essentially says that the
number
> of
> > buckets needs to be positive, or equivalently that we need space for at
least
> > one element in a vector to store the result.
> 
> Don't use stdlib assert(). gtest's ASSERT_nn or EXPECT_nn should work fine
here.

ASSERT does not work since the function does not return void. EXPECT would
compile, but the program would likely crash when trying to execute the
subsequent lines after a failure.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:25: assert(n > 0);
On 2015/11/27 11:06:28, pbos-webrtc wrote:
> On 2015/11/27 11:02:10, the sun wrote:
> > On 2015/11/27 10:35:24, terelius wrote:
> > > On 2015/11/25 10:12:37, the sun wrote:
> > > > ASSERT_GT()
> > > 
> > > ASSERT requires a void function. In this case I think it is perfectly
> > reasonable
> > > to kill the test upon triggering the assertion since the assertion is a
> sanity
> > > check on the test case itself. The assertion essentially says that the
> number
> > of
> > > buckets needs to be positive, or equivalently that we need space for at
> least
> > > one element in a vector to store the result.
> > 
> > Don't use stdlib assert(). gtest's ASSERT_nn or EXPECT_nn should work fine
> here.
> 
> Feel free to use RTC_(D)CHECK_GT if all else fails. :)

Yeah, that would work. Thanks.

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/base/random_unitt...
webrtc/base/random_unittest.cc:288: // sample is in the interval [n-0.5, n-0.5].
On 2015/11/27 11:02:10, the sun wrote:
> On 2015/11/27 10:35:24, terelius wrote:
> > On 2015/11/25 10:12:37, the sun wrote:
> > > That's an awfully small interval.
> > 
> > In this test, we draw a real number x from a gaussian distribution and round
> it
> > to the nearest integer n.
> > 
> > We want to know the probability of getting a particular integer n. If x is
> > rounded to n, then x must be in the interval [n-0.5, n+0.5). The probability
> > that x is in [a, b) is the integral from a to b of the probability density
> > function p(x). Since the interval is fairly small, we can estimate the
> integral
> > using a small number of points. The previous version of this test (located
in
> > remote_bitrate_estimator) used only one point. I increased it to 3 points to
> get
> > a more accurate estimate, but the difference is likely small for the
> parameters
> > we are testing.
> > 
> 
> But isn't the comment wrong? "[n-0.5, n-0.5]"

Oh, sorry. Updated comment.

[terelius, 2015-11-27 12:54:32]

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/modules/remote_bi...
File webrtc/modules/remote_bitrate_estimator/test/bwe_test_framework_unittest.cc
(right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/modules/remote_bi...
webrtc/modules/remote_bitrate_estimator/test/bwe_test_framework_unittest.cc:538:
// The expected number of swaps we perform is PacketCount - 1,
On 2015/11/25 10:12:38, the sun wrote:
> expected->maxiumum

I mixed the formula for the maximum with a comment about the expectation. I
think it is more meaningful to talk about the expected number of swaps, so I'll
update the expression to p * (PacketCount - 1) instead.

Well spotted!

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/modules/remote_bi...
webrtc/modules/remote_bitrate_estimator/test/bwe_test_framework_unittest.cc:542:
// pair is p * (1-p). Since there are (kPacketCount - 1) independent pairs,
On 2015/11/25 10:12:38, the sun wrote:
> super nit: "1-p" -> "1 - p"
> 
> Also, if would care to give me a short math lesson, that'd be appreciated! :)

Done, I think?

[the sun, 2015-11-27 13:37:26]

lgtm

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/modules/remote_bi...
File webrtc/modules/remote_bitrate_estimator/test/bwe_test_framework_unittest.cc
(right):

https://codereview.webrtc.org/1457023002/diff/100001/webrtc/modules/remote_bi...
webrtc/modules/remote_bitrate_estimator/test/bwe_test_framework_unittest.cc:542:
// pair is p * (1-p). Since there are (kPacketCount - 1) independent pairs,
On 2015/11/27 12:54:32, terelius wrote:
> On 2015/11/25 10:12:38, the sun wrote:
> > super nit: "1-p" -> "1 - p"
> > 
> > Also, if would care to give me a short math lesson, that'd be appreciated!
:)
> 
> Done, I think?

Yes, thank you! :)

[pbos-webrtc, 2015-11-27 13:41:32]

lgtm

[mflodman, 2015-11-30 09:19:23]

base/ LGTM

[the sun, 2015-12-02 14:45:38]

solenberg@webrtc.org changed reviewers:
- solenberg@google.com

[stefan-webrtc, 2015-12-10 08:15:14]

lgtm for webrtc/modules/remote_bitrate_estimator

[terelius, 2015-12-10 09:34:13]

The CQ bit was checked by terelius@webrtc.org

[terelius, 2015-12-10 09:34:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
solenberg@webrtc.org, pbos@webrtc.org, mflodman@webrtc.org, stefan@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1457023002/#ps240001 (title:
"Rebase")

[commit-bot: I haz the power, 2015-12-10 09:34:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1457023002/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1457023002/240001

[commit-bot: I haz the power, 2015-12-10 09:50:58]

Description was changed from

==========
Rewrote the PRNG using an xorshift* algorithm and moved the files from test/ to
base/.

Created a simple unit test for the new random number generator. (It mostly tests
that the generated numbers are consistent with the intended distribution, e.g.
uniform.
It is not a comprehensive test of the quality of the random numbers.)

Several assertions in OveruseDetectorTest seem to depend on the exact sequence
of random numbers. I updated those numbers to work with the new PRNG.

Compute the standard deviation of the expected result in TestReorderFilter
instead of passing an uncertainty parameter.

BUG=webrtc:5177
==========

to

==========
Rewrote the PRNG using an xorshift* algorithm and moved the files from test/ to
base/.

Created a simple unit test for the new random number generator. (It mostly tests
that the generated numbers are consistent with the intended distribution, e.g.
uniform.
It is not a comprehensive test of the quality of the random numbers.)

Several assertions in OveruseDetectorTest seem to depend on the exact sequence
of random numbers. I updated those numbers to work with the new PRNG.

Compute the standard deviation of the expected result in TestReorderFilter
instead of passing an uncertainty parameter.

BUG=webrtc:5177
==========

[commit-bot: I haz the power, 2015-12-10 09:50:58]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2015-12-10 09:51:09]

Description was changed from

==========
Rewrote the PRNG using an xorshift* algorithm and moved the files from test/ to
base/.

Created a simple unit test for the new random number generator. (It mostly tests
that the generated numbers are consistent with the intended distribution, e.g.
uniform.
It is not a comprehensive test of the quality of the random numbers.)

Several assertions in OveruseDetectorTest seem to depend on the exact sequence
of random numbers. I updated those numbers to work with the new PRNG.

Compute the standard deviation of the expected result in TestReorderFilter
instead of passing an uncertainty parameter.

BUG=webrtc:5177
==========

to

==========
Rewrote the PRNG using an xorshift* algorithm and moved the files from test/ to
base/.

Created a simple unit test for the new random number generator. (It mostly tests
that the generated numbers are consistent with the intended distribution, e.g.
uniform.
It is not a comprehensive test of the quality of the random numbers.)

Several assertions in OveruseDetectorTest seem to depend on the exact sequence
of random numbers. I updated those numbers to work with the new PRNG.

Compute the standard deviation of the expected result in TestReorderFilter
instead of passing an uncertainty parameter.

BUG=webrtc:5177

Committed: https://crrev.com/84e78f9102dfbe9fc17aecd8d9d816042425a294
Cr-Commit-Position: refs/heads/master@{#10965}
==========

[commit-bot: I haz the power, 2015-12-10 09:51:11]

Patchset 13 (id:??) landed as
https://crrev.com/84e78f9102dfbe9fc17aecd8d9d816042425a294
Cr-Commit-Position: refs/heads/master@{#10965}