Alexey Kuleshevich

CI is still failing

I was not originally involved in implementing floating point number generation, it was mostly @Shimuuar and @curiousleo that handled it when we did the rewrite in 2020. So, I had...

I decided to play around a bit with [`sbv`](https://hackage.haskell.org/package/sbv) and was able to verify this claim, which is an improvement over what we have today IMHO: > This approach also...

> As far as I can tell, you formulated the constraints in a way such that they are unsatisfyable and I guess that was intentional so a SAT solver can...

> While investigating some ideas, I actually noticed an actual problem with the proposed solution: The sub-term h - l (or l - h) might overflow to infinity if l...

> On the contrary it's slightly better wrt to randomness. @Shimuuar Oh yeah you are right. I do like that! However, it also has the same problem of overflowing: https://github.com/haskell/random/issues/166#issuecomment-2561983024...

@Shimuuar are you suggesting something along these lines: ```haskell uniformFRM :: StatefulGen g m => (Float, Float) -> g -> m Float uniformFRM (l, h) g | l == h...

We could even further clamp the values for the `isInfinite diff` case in order to ensure that generated values do not go out of supplied `h` and `l` bounds: ```haskell...

> Although I'm not sure that trick with testBit will buy us anything in isInfinite diff==True Good point. This is the final draft that I have: ```haskell w

I've adjusted my PR: https://github.com/haskell/random/pull/172 Please leave feedback and if there will be no objections, I will make a new release with a fix later on today