[leiroigh]

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.

[camel-cdr]

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.

[leiroigh]

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?

[camel-cdr]

But what if you want a random number between two very small floats?

[leiroigh]

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