On Fri, 5 Dec 2025 at 13:51, Juan Lucas Rey <juanlucasrey_at_[hidden]> wrote:

> Hi,
>
> "What do you mean by "discard RNGs"? Deterministically discard values
> produced from RNGs?"
>
> Yes. Assume I want to simulate 10.000 Monte Carlo paths in one process
> and the next 10.000 Monte Carlo paths in another process. Assuming I
> know that each path uses Y RNGs, then I would have to call
> rng.discard(10000 * Y) on the second process before using it.
> With p0952r2 now I need to actually produce the numbers with
> "canonical_distribution", and if any of those gives 1.0 I have to add
> 1 to 10000 *Y. This defeats the purpose of having fast discard
> methods.
>

You keep saying "canonical_distribution" ... do you mean
std::generate_canonical, or one of the random number distributions in
<random>, or some non-standard random number distribution in your own code?


>
> "That could be achieved the same way libstdc++ does it: when
> generate_canonical would return 1.0, just return
> std::nextafter(RealType(1), RealType(0)) instead. We don't need a
> completely different function that doesn't return values in the range
> [0,1) and which needs every caller to be adjusted for the new output
> range."
>
> My proposal actually allows for more control. say for example all 10
> values [RNG::max() -10, RNG::max()] return 1.0 with
> canonical_distribution. libstd++ proposes to return
> std::nextafter(RealType(1), RealType(0)) for these 10 values. What I
> am proposing is to return different values for those 10 results,
> allowing for better distribution and avoiding the loss of information
> from multiple distinct RNG outputs being mapped to the same
> floating-point value.
>

But your proposal returns negative numbers for those 10 values. It's highly
debatable whether that is a "better distribution" given that those values
are outside the [0,1) range!
Your results might be more uniformly distributed over some range, but it's
a different range!


>
> From what you tell me then though, it is not worth pursuing this
> further because of timing?
>


It's going to be very difficult to change anything now.

If you want to try to convince the committee to undo the P0952 changes
(maybe as a defect report against C++26) then your proposal needs to
explain (in detail!) why the new spec is a problem. Not just say "here's a
different function with different properties". Proposing a completely
different function won't change anything about the current contents of the
<random> header.

And if you don't want to change anything in <random>, but just need some
other function for your own uses, why does that need to be in the standard?
You can already use the function yourself.