Nick Sabalausky wrote:
"Don" <nos...@nospam.com> wrote in message
news:gnb7mt$2os...@digitalmars.com...
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.
I would think that, with the possible exception of mathematicians, most of
the time anyone would want a random floating-point number they would
consider +/-infinity a special case. Most non-math-oriented code isn't
really designed to handle infinity anyway. Besides, technically, double also
includes NaN ;)
You're asking for a random *number* and NaN is not a number :).
If you have a double x, which could be double.max, -double.max, 0.0,
-double.min*double.epsilon, or +double.min*double.epsilon, there's
hardly any operations you can do on it which won't generate an infinity
or NaN.
But cutting out infinity doesn't help much -- anything from the range of
double will be really close to double.max. If the code is correct, it's
still going to have to deal with infinity.
double d = uniform(NumericInterval.DOUBLE);
d *=2;
// BUG: There's a 50% chance that d is now +- infinity.
