Hi,

"It should be noted that it is not specified how or when any of the
random distributions in <random> use std::generate_canonical."

why is "LWG issue 2524" mentioned the in
https://en.cppreference.com/w/cpp/numeric/random/exponential_distribution.html
then?
If LWG issue 2524 is exclusively concerning "std::generate_canonical",
and if it is not specified that "std::exponential_distribution" should
use "std::generate_canonical" then don't understand why that issue is
mentioned there.

I infer from this that any implementation issues on
"std::exponential_distribution" returning infinity should be solved
independently from LWG issue 2524 (which concerns only
"std::generate_canonical"). Is that correct?

Lucas

On Fri, 5 Dec 2025 at 14:06, Juan Lucas Rey <juanlucasrey_at_[hidden]> wrote:
>
> "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?"
>
> I mean std::generate_canonical, yes.
>
> "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!"
>
> My suggestion to use "generate_canonical_centered" inside
> "std::exponential_distribution" (as proposed in the sample file I
> sent) does return 10 different values for the extremes. what libstd++
> is proposing is to return the same value for those 10 cases. As
> explained before, the purpose here is to have that different range,
> containing better precision, especially in the right limit, being
> properly handled in the other distributions.
>
> Lucas
>
>
>
> On Fri, 5 Dec 2025 at 13:59, Jonathan Wakely <cxx_at_[hidden]> wrote:
> >
> >
> >
> > 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.
> >