Andrei Alexandrescu wrote:
Yigal Chripun wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
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.
My point was that realloc() is wrong, not free(). The sorely missing
allocation primitive is expand(), and we've been paying for it through
the nose for decades.
Andrei
I see.
Having 3 functions: malloc(), expand() and free() is indeed a very good
design.
regarding the original topic, I still generally prefer bearophile's API,
random may be omitted and other small changes are also possible but it
looks better to me than using something like:
uniform!("[]")(rng, a, b);
maybe some aliases are in order?
