default random object?

[Benji Smith]

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)?

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