I started getting into the idea of how many random numbers can be generated between 0 and 1 in a double variable in GML , so I googled it and found this article in stackoverflow.com ...

Assuming that:

- we're talking about double precision floating point values (in general, not tied to GML)
- we want to generate values greater than or equal to 0, but strictly less than 1
- we don't want to generate negative 0
- we want every distinct generatable value to have equal odds of being generated
- we want for any numbers A, B and D such that A >= 0, B >= 0, A+D < 1 and B+D < 1, that the odds of generating a value greater than or equal to A, but less than A+D equals the odds of generating a number greater than or equal to B, but less than B+D (or in short, we want generated numbers to be approximate a uniform distribution of real numbers in the range [0,1[)
- we want the set of generatable values to be as large as possible while following the above rules

The amount of generatable values is exactly 2^53, where each value has the form "N / 2^53" with N >= 0 and N < 2^53.

This is as the stackoverflow response also indicates.

So in GML you can assign a number that can not be randomly generated in a double to a double variable, but you cant prove that it is one those numbers that can not be randomly generated between 0 and 1......since you will never see it produced by the random number generator.....

If you know the algorithm (or even part of the algorithm) that produces the pseudo random numbers, than you can prove it.

If you assume the randomly generated numbers are as described by the stack overflow reply, then you can also very easily determin if a value is generatable by the pseudo random generator.

If the value is NaN or negative zero, than it isn't generatable.

If the value is 1 or greater than 1, it isn't generatable.

If the value is less than 0, it isn't generatable.

If the value multiplied by 2^53 has a fractional part, it isn't generatable.

Otherwise, the value is generatable.

So the idea that I am understanding is, if your randomly generating numbers between 0 and 1, will you __always__ get the same numbers values no matter how many times you run the program ( including the use of the randomize function ) in GML.....

It's not clear to me what you mean with this.

Do you mean that there is a finite set of generatable numbers that contains all the values that can be generated by a specific pseudo random number generator algorithm?

Well, then of course.

That's already a given by the fact that a computer only has a finite amount of memory.

However, we're speaking about 2^53 different values.

That's 9,007,199,254,740,992 different possible combinations.

If you can generate a pseudo random number every nanosecond (which would be pretty fast) and you keep generating numbers one immediately after the other and you keep producing distinct values,

then it would still take you more than 104 days to generate all those values.

I wouldn't exactly call that generating the same values every time again.

If we assume that it first generates an integer between [0, INT_MAX), and then divides 1.0 by it, then you will only get a subset of all possible doubles (in increments of 1/INT_MAX).

I think you meant "and then divide it by INT_MAX", because you wouldn't get increments of 1/INT_MAX otherwise.

I'm somewhat confident that 1/INT_MAX is smaller than a double's precision (Assuming a 64 bit int).

This statement is poorly defined.

If you mean that 1/INT_MAX is smaller than the difference between 0.5 and the smallest larger double precision floating point value, then yes, it is.

So you can pretty much assume any possible double can come out of the random function.

If you mean every possible double precision floating point value between 0 and 1, including 0 and 1, then no.

If you get close enough to 0, you get more absolute precision, allowing to represent values that do net get generated by the function.

The general rule to not compare == floating points still apply though. Don't check if two doubles are equal. Instead, check if they fall within a range.

In GameMaker, comparing using == checks for a range by default (unless GM:S 2 changed that much since I last used it).

Whether exact comparison is preferable depends on what you want to do, but in dame dev fuzzy comparisons tend to always be preferable when working with floating point precision.

I'm not sure why it is relevant in this discussion however.

Aside:

When dealing with known ranges (0 to 1 for example). It's often better to normalize that range and represent it as an integer (0 - INT_MAX). This gives you more precision. Although I don't know if this translates to any real gains when using GML where you don't have much control over type.

Transforming generated numbers can only make you lose precision.

Having larger numbers doesn't give you more precision when working with floating point precision.

If using a system like the stack overflow reply indicates, then normalizing the the value to be in range (0 - INT_MAX) wouldn't change anything in the precision or bit representation of the value, except that the exponent is a bit larger.

EDIT:

I made a mistake in my assumptions list.

A and B are generatable numbers.

Otherwise, the assumptions would not be satisfiable.