[erlang-questions] On OTP rand module difference between OTP 19 and OTP 20
Fri Sep 1 14:06:44 CEST 2017
On Fri, Sep 01, 2017 at 03:53:37AM -0700, Michael Truog wrote:
> On 09/01/2017 01:41 AM, Raimo Niskanen wrote:
> >> I have some examples that can make this desire a bit clearer:
> >> https://github.com/CloudI/cloudi_core/blob/a1c10a02245f0f4284d701a2ee5f07aad17f6e51/src/cloudi_core_i_runtime_testing.erl#L139-L149
> >> % use Box-Muller transformation to generate Gaussian noise
> >> % (G. E. P. Box and Mervin E. Muller,
> >> % A Note on the Generation of Random Normal Deviates,
> >> % The Annals of Mathematical Statistics (1958),
> >> % Vol. 29, No. 2 pp. 610–611)
> >> X1 = random(),
> >> X2 = PI2 * random(),
> >> K = StdDev * math:sqrt(-2.0 * math:log(X1)),
> > math:log(X1) will badarith if X1 =:= 0.0. You need a generator for X1
> > that does not return 0.0, just as RO'K says.
> >> Result1 = erlang:max(erlang:round(Mean + K * math:cos(X2)), 1),
> >> Result2 = erlang:max(erlang:round(Mean + K * math:sin(X2)), 1),
> > If random() for X2 is in [0.0,1.0] then both 0.0 and 1.0 will produce the
> > same value after math:cos(X2) or math:sin(X2), which I am convinced will
> > bias the result since that particular value will have twice the probability
> > compared to all other values. I think you should use a generator for X2
> > that only can return one of the endpoints.
> > Actually, it seems a generator for (0.0,1.0] would be more appropriate
> > here...
> >> sleep(Result2),
> >> with:
> >> random() ->
> >> quickrand:strong_float().
> >> These are code segments used for the CloudI service configuration options monkey_latency and monkey_chaos so that normal distribution latency values and random service deaths can occur, respectively (with the more common names as Latency Monkey and Chaos Monkey, but the words switched to make the concepts easier to find and associate). For the Box-Muller transformation, it really does want a definite range [0,1] and it helps make the monkey_chaos service death easier to understand at a glance.
> > Please explain why the Box-Muller transformation needs a definite range
> > [0.0,1.0].
> That was my understanding after not having modified that routine for a decent amount of time, though I must be mistaken. I will need to fix this source code and regret not seeing these problems in the Box-Muller transformation source code. Thank you for pointing them out. At least this shows a need for a (0.0,1.0] function.
Yes. That is easily produced by (pointed out earlier in this thread):
1.0 - rand:uniform()
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions