News for hackers. Stuff that matters.
Re:Higher Quality Random Floats by leiroigh on Wednesday October 18, 2023 @07:24AM (#37927190)
I don't think that would be a good idea -- sticking to positive normals and truncating below is enough for float32 and float64. I mean, consider that 1.1754944f-38 is a normal 32 bit float.

The probability that your "perfect" code would ever get triggered is such that humankind has not built enough compute to expect to get that unlucky yet.

(you may ask: why then care about that possibility if it's dead code anyway? Because of security vulns in context of flawed RNGs. Bad underlying RNG leading to bad distributions is expected; bad underlying RNG leading to RCE is not OK. So don't ever output zero or subnormals!)

For bfloat16 the same holds; for ieee float16, well, I have no clue what we want.

Re:Higher Quality Random Floats by camel-cdr on Wednesday October 18, 2023 @07:30AM (#37927228)
I don't think such a function would be a good default, but I think there may be applications, probably some complex very large simulations, where this might matter.
Re:Higher Quality Random Floats by leiroigh on Wednesday October 18, 2023 @07:47AM (#37927339)
You think there might be applications like complex very large simulations where an event with probability 1:10^38 matters?

You are aware that the current age of the universe is < 10^27 nanoseconds, just for comparison?

Re:Higher Quality Random Floats by camel-cdr on Wednesday October 18, 2023 @07:53AM (#37927381)
But what if you want a random number between two very small floats?
Re:Higher Quality Random Floats by leiroigh on Wednesday October 18, 2023 @08:24AM (#37927615)
Fair enough, if a user asks for a random float between [0, 1e-38f] then subnormals are expected.

I was just thinking about the (0,1) case, under the mistaken assumption that one could map it to (a,b) via multiplication/addition, but you're right -- if you want (a,b) perfectly () then it's not obvious to me.

() up to inaccuracies of cosmologically negligible scale