default random object?

[Yigal Chripun]

Andrei Alexandrescu wrote:
> bearophile wrote:
>> Andrei Alexandrescu:
>>
>>> 3. How should the global rng be initialized?
>>
>> Automatically seeded with the time at the beginning of the program. Of
>> course the seed can be set again in any moment.
>>
>>
>>> 4. While we're at it, should uniform(a, b) generate by default
>>> something in [a, b] or [a, b)? Someone once explained to me that
>>> generating [a, b] for floating point numbers is the source of all
>>> evils and that Hitler, Stalin and Kim Il Sung (should he still be
>>> alive) must be using that kind of generator. Conversely, generating
>>> [a, b) is guaranteed to bring in the long term everlasting peace to
>>> Earth. My problem however is that in the integer realm I always want
>>> to generate [a, b]. Furthermore, I wouldn't be happy if the shape of
>>> the interval was different for integers and floating point numbers.
>>> How to break this conundrum? Don't forget that we're only worrying
>>> about defaults, explicit generation is always possible with
>>> self-explanatory code:
>>> auto rng = Random(unpredictableSeed);
>>> auto a = 0.0, b = 1.0;
>>> auto x1 = uniform!("[]")(rng, a, b);
>>> auto x2 = uniform!("[)")(rng, a, b);
>>> auto x3 = uniform!("(]")(rng, a, b);
>>> auto x4 = uniform!("()")(rng, a, b);
>>
>> That's awful and ugly. My suggestions are simple (copied from my dlibs
>> and the random std lib of Python):
>>
>> random() => floating point [0, 1)
>> randInt(a=0, b) => integral [a, b]
>> randRange(a=0, b) => integral [a, b)
>> uniform(a, b) => floating point [a, b)
>> normal(a, b) => good quality normally-distributed number with given
>> std dev and avg.
>
> Leaving normal() aside (does your implementation implement the ziggurat
> algorithm? If so, would you agree to contribute it to phobos?), I don't
> see how having to memorize four names instead of one is necessarily
> awesome and beautiful. Besides uniform() renders "random" redundant.
> Hardly a pinnacle of good API design, see realloc() which essentially
> makes malloc() and free() redundant.
>
> Andrei

your example counters your claim.
The same reason we prefer to use D with so many concepts and keywords 
over something like brainf**k that is turing-complete with just 8 or so 
commands can be apllied here.
sure, the *implementation* of realloc() makes the *implementations* of 
free() and malloc() redundunt but it's easier to remember to use free() 
when you actually want to free something. if free() wasn't available, 
the first thing I'd do was to use a macro to define it.