What do you mean by "normally distributed values"? Your reply also doesn't follow a normal distribution by the way. Did you mean uniform? For uniform values there is a way to go and my other reply exactly describes how.
Of course, it's uniform. I always swap the two names randomly hehe.
I understand your code. The difference with the snippet I posted (which, btw,
is not mine) is that the difference between successive floats is always a constant, i.e. there is no rounding.
It's fast, has 23 bits of entropy and it's suited for constrained platforms/small demos [0], since it can be coded with very few asm instructions.
I'm not saying that your solution hasn't its merits, well done.
[0] The author of the code is a known member of the demoscene
Oh, I know very well who iq is :) And for a visual demo it might make perfect sense to sacrifice completeness of a solution for speed / code size. But to me, "pick a random number from {k/2^23 : 0 <= k < 2^23, k ∈ ℕ}" and "pick a random number uniformly at random from [0, 1)" are not the same.
All operations (add/sub, mul/div, sin, exp, log, etc...), with IEEE754 floats are defined using real arithmetic, and then assumed to round to the nearest representable floating point value. I don't see why random number generation, at least as a default before micro-optimizing, should be any different.
You are right, I was uncomfortable with the uneven density of the floats approaching zero, but it's just an inherent property of their representation.
Have a nice day :)
I'm not saying that your solution hasn't its merits, well done.
[0] The author of the code is a known member of the demoscene