On Mon, Feb 16, 2009 at 3:51 AM, Andrei Alexandrescu <seewebsiteforem...@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