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
