On Wednesday, 24 April 2013 at 10:33:49 UTC, Ivan Kazmenko wrote:
> On Wednesday, 24 April 2013 at 10:26:19 UTC, Andrea Fontana wrote:
>>> I'd like to mention that there's no such mathematical object as "uniform distribution on [0..+infinity)".
>>
>> ... you neither can choose a random real number in any interval ...
>
> ... but that is at least valid mathematically, albeit achievable only approximately on a computer.  On the other hand, an infinite case, even if it would be possible, won't be practical anyway since with probability 1, the result would require more bits to store than available on any modern hardware.

I mean that a random real number is not valid mathematically too. In any given real interval there are infinite numbers, how you can choose a number in an infinite (and non-numerable!) interval? I think you always need some sampling.

What's the probability to guess a precise number in [0..1]? I think is 0 as long as you have infinite numbers.

What's the probability to guess a interval in [0..1]? I think it's the interval size.

Am I wrong?

On Wednesday, 24 April 2013 at 10:46:57 UTC, Andrea Fontana wrote:
> What's the probability to guess a precise number in [0..1]? I think is 0 as long as you have infinite numbers.

Right.

> What's the probability to guess a interval in [0..1]? I think it's the interval size.

Right again.

> I mean that a random real number is not valid mathematically too. In any given real interval there are infinite numbers, how you can choose a number in an infinite (and non-numerable!) interval? I think you always need some sampling.
>
> Am I wrong?

In a sense, yes.  A continuous probability distribution is well-defined.  In short, as you pointed out, you can coherently define the probabilities to hit each possible segment and get a useful mathematical object, though the probability to hit each single point is zero.  It's no less strict than a typical high school definition of an integral.  See the link for more info: http://en.wikipedia.org/wiki/Probability_distribution#Continuous_probability_distribution .

On Wednesday, 24 April 2013 at 06:56:44 UTC, Ivan Kazmenko wrote:
> On Wednesday, 24 April 2013 at 06:37:50 UTC, qznc wrote:
>> It also raises the question what uniform means in the context of floating point. Uniform over the numbers or uniform over
>> the bit patterns?
>
> I'd like to mention that there's no such mathematical object as "uniform distribution on [0..+infinity)".  On the other hand, a (discrete) uniform distribution of the bit pattern, or restricted bit pattern (that is, no special values), is of course valid.  A "random positive double" as a bit pattern most closely resembles exponential distribution I think.

Of course not, since infinity is not a number.

However, double.max is not infinity, but 0x1p+1024. See http://dlang.org/d-floating-point.html

On Tuesday, 23 April 2013 at 14:43:15 UTC, qznc wrote:
> I want to generate a random "double" value, excluding wierdos like NaN and Infinity. However, std.random.uniform seems to be useless. I tried things like
>
>   std.random.uniform( double.min, double.max);
>   std.random.uniform(-double.max, double.max);
>   std.random.uniform(0.0, double.max);
>
> However, I just get Inf values. :(

I've just tried to reproduce that. The first line gives a deprecation warning, the second gives infinities, but the third line does give me non-infinities.  I've checked that under DMD 2.062 on Windows, and the hardware is Intel Xeon E5450.

Here is an example:

-----
import std.random;
import std.stdio;

void main ()
{
	foreach (i; 0..5)
	{
		double x = uniform (-double.max, +double.max);
		writefln ("%25a %30.20g", x, x);
	}

	foreach (i; 0..5)
	{
		double x = uniform (          0, +double.max);
		writefln ("%25a %30.20g", x, x);
	}
}
-----

And an example output is:

-----
                      inf                            inf
                      inf                            inf
                      inf                            inf
                      inf                            inf
                      inf                            inf
  0x1.9d6fad0f9d6f9p+1023     1.4516239851099787345e+308
  0x1.b53e4c11b53e3p+1020      1.919017005286872499e+307
  0x1.5dc7e6d15dc7dp+1020     1.5351529811186840176e+307
  0x1.bd608187bd606p+1023     1.5637717442069522658e+308
  0x1.e38d5871e38d4p+1023     1.6978092693521789428e+308
-----

Perhaps "std.random.uniform(-double.max, double.max);" call does indeed cause overflow.  If the example does not work for you, try "double.max / 2" or "double.max / 4" boundary instead.

That said, note that the values generated this way will have exponent close to the maximal possible (1024), and that may be not the only case you wish to cover.  Your suggestion to generate 64-bit patterns instead of real numbers, probably excluding special values (all-0 or all-1), sounds like the way to go.  I'd include some important cases (like +-0 and +-1) manually too.

Ivan Kazmenko.

On Wednesday, 24 April 2013 at 13:30:41 UTC, Ivan Kazmenko wrote:
> probably excluding special values (all-0 or all-1),
I meant exponent bits being all 0 or all 1, sorry.  That's where the special values reside, at least according to IEEE-754-1985 here: http://en.wikipedia.org/wiki/IEEE_754-1985

On 04/23/2013 10:59 PM, bearophile wrote:
> Also note by their nature doubles are not equally spread across the line of Reals, so getting a truly uniform distribution is hard or impossible.

More than that -- the number of unique values generated by the underlying RNG should (for Mersenne Twister) be much smaller than the number of unique double values in [-double.max, double.max], because the type used is uint32.

I think the infinities probably come from the fact that the returned random value is generated by the following expression:

       _a + (_b - _a) * cast(NumberType) (urng.front - urng.min)
       / (urng.max - urng.min);

So, you've got a double.max + (double.max - double.min) in there which evaluates
to inf.

On 04/23/2013 11:46 PM, qznc wrote:

> Tue, 23 Apr 2013 13:49:48 -0700: Ali Çehreli wrote

>> Unfortunately, that will not produce a uniform distribution. The results
>> will mostly be in the range [-0.5, 0.5]. The lower and higher values
>> will have half the chance of the middle range:
>
>
> Interesting. Why [-0.5,0.5], though? I would have expected [-1.0,1.0] from
> Clugston's article.
>
> http://dlang.org/d-floating-point.html

Hmmm... I don't know. Interestingly, I wrote that *before* running the test program, which has confirmed it. So, I was correct without knowing why. :)

Ali