default random object?

[Don]

Benji Smith wrote:
> Don wrote:
>> Benji Smith wrote:
>>> Don wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> Benji Smith wrote:
>>>>>> Benji Smith wrote:
>>>>>>> Maybe a NumericInterval struct would be a good idea. It could be 
>>>>>>> specialized to any numeric type (float, double, int, etc), it 
>>>>>>> would know its own boundaries, and it'd keep track of whether 
>>>>>>> those boundaries were open or closed.
>>>>>>>
>>>>>>> The random functions would take an RND and an interval (with some 
>>>>>>> reasonable default intervals for common tasks like choosing 
>>>>>>> elements from arrays and random-access ranges).
>>>>>>>
>>>>>>> I have a Java implementation around here somewhere that I could 
>>>>>>> port to D if anyone is interested.
>>>>>>>
>>>>>>> --benji
>>>>>>
>>>>>> Incidentally, the NumericInterval has lots of other interesting 
>>>>>> applications. For example
>>>>>>
>>>>>>    auto i = NumericInterval.UBYTE.intersect(NumericInterval.SBYTE);
>>>>>>    bool safelyPolysemious = i.contains(someByteValue);
>>>>>>
>>>>>>    auto array = new double[123];
>>>>>>    auto i = NumericInterval.indexInterval(array);
>>>>>>    bool indexIsLegal = i.contains(someIndex);
>>>>>>
>>>>>> Using a numeric interval for generating random numbers would be, 
>>>>>> in my opinion, totally ideal.
>>>>>>
>>>>>>    double d = uniform(NumericInterval.DOUBLE); // Any double value
>>>>>
>>>>> I've never been in a situation in my life where I thought, hey, a 
>>>>> random double is exactly what I'd need right now. It's a ginormous 
>>>>> interval!
>>>>>
>>>>> Andrei
>>>>
>>>> It's worse than that. Since the range of double includes infinity, a 
>>>> uniform distribution must return +-infinity with probability 1. It's 
>>>> nonsense.
>>>
>>> Way to miss the forest for the trees.
>>>
>>> You guys telling me can't see any legitimate use for a 
>>> NumericInterval type? And that it wouldn't be convenient to use for 
>>> random number generation within that interval?
>>>
>>> So the full double range was a dumb example. But that wasn't really 
>>> the point, was it?
>>>
>>> --benji
>>
>> On the contrary, I've been giving NumericInterval considerable thought.
>> One key issue is whether a NumericInterval(x1, x2) must satisfy x1 <= 
>> x2 (the _strict_ definition), or whether it is also permissible to 
>> have x2<=x1 (ie, you can specify the two endpoints in reverse order; 
>> the interval is then between min(x1,x2) and max(x1, x2)).
>>
>> This is an issue because I've noticed is that when I want to use it, I 
>> often have related pairs of values.
>> eg.
>> Suppose u is the interval {x1, x2}. There's a related v = {f(x1), f(x2)}.
>> Unfortunately although x1<=x2, f(x1) may not be <= f(x2). So v is not 
>> an interval in the _strict_ sense. But it satisfies the _relaxed_ 
>> definition.
> 
> I don't see any idealogical reason for requiring x2 >= x1.
> 
> But the public API of the interval will probably have functions or 
> properties returning the "lowerBound" and "upperBound". And the 
> implementations of the "containsValue", "intersect", and "overlap" 
> functions are all more straightforward to write if you know in advance 
> which value is which, potentially switching them in the constructor.
> 
> Of course, if you switch the values, do you also switch the boundary 
> open/closed boundaries? What about this case:
> 
>    auto i = Interval!("[)")(1000, -1000);
> 
> Which side of the range is open, and which is closed? Does the "[)" 
> argument apply to the natural order of the range (closed on its lower 
> bound) or does it apply to the order of the arguments in the function 
> (closed on its leftmost argument)?

That's a really good question, and probably the killer argument against 
relaxed ranges.

A NumericInterval would always be stored internally as "[]", so the "[)" 
is only required at construction/assignment (it's not part of the type).
So instead, it seems as though a different type is required (a pair of 
values), which provides conversion to a strict range. Not as simple as I 
hoped.

> As long as the behavior is well documented, I think it'd be fine either 
> way. But I also think it'd be reasonable to throw an exception if the 
> arguments are in the wrong order.
> 
> --benji