default random object?

[Bill Baxter]

On Mon, Feb 16, 2009 at 3:51 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>>
>> I guess I'd find it more useful to have a function that gave a random
>> value of a given type, like random_value!(short).  That way you get
>> the signed/unsigned specification automatically.  But both could be
>> useful.
>
> You can, just pass short values into uniform() or specify type arguments for
> it. Actually uniform() used to ask compulsively for its parameter type, but
> I changed that because it was too verbose for no good reason.
>
>>> * If you're creating a number in the range 0..uint.max+1, you're going to
>>> have to be careful in lots of places. You can't get that number from an
>>> array length, for example.
>>> * I think that hard-core scientific/mathematical users are the main users
>>> of
>>> the more esoteric cases, and can be expected to get it right (and have no
>>> problem with the "[]","()","(]"... notation. I think that what's
>>> important
>>> for the default is that be correct and obvious for as many cases as
>>> possible.
>>>
>>> The strength of "[)" is that if we can say "ALL ranges in D are [) unless
>>> otherwise stated by the user", it's hard to ever justify breaking that
>>> convention.
>>
>> That sounds reasonable to me.  As long as there's an easy way to also
>> create a random number that covers an entire range of a given type
>> (perhaps limited to integral types).
>
> It's a good litmus test. With the API suggested by Don, in order to generate
> a random byte you'd have to say:
>
> auto b = uniform!("[]")(rng, byte.min, byte.max);
>
> Is this acceptable?

If that's what it took I'd probably try this instead:
ubyte b = uniform(rng, 0,256);

And then add an explicit cast to ubyte if the compiler didn't like that.
So no, I don't really think that's good enough.  Others may disagree
about how important a use case this is, though.

--bb