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

> 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?
>

I don't know, some editor of that page thought it was relevant. That's not
the standard, so I don't really care what it says.

It's true that *in practice* implementations of
std::exponential_distribution use std::generate_caonical, but they aren't
required to. The standard doesn't say they have to. And it doesn't say they
can only call it once.



> 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.
>

Ask the person who edited that link into the page. You're asking about an
unofficial, third-party website that provides user docs for the standard,
but that's not the standard.

It's probably because LWG 2524 was originally reported as a defect in
std::exponential_distribution, but as explained in LWG 2524, there's no
defect in std::exponential_distribution. The real defect was identified to
be in std::generate_canonical, and that's why LWG 2524 was renamed, and why
P0952R2 changed std::generate_canonical.


>
> 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?
>

Any implementation issues in std::exponential_distribution are exactly
that: implementation issues. They have nothing to do with the standard if
they're bugs in implementations.

As explained in LWG 2524, real implementations use std::generate_canonical,
assuming that it works as described in the standard. But it doesn't, and
*that* is a defect in the standard. With a std::generate_caonical that
meets its contract and returns uniformly distributed values in the range
[0,1), existing implementations of std::exponential_distribution work fine
- they don't have any remaining bugs (as far as I know).

If your implementation still returns infinity with a
std::generate_canonical that never returns 1.0, that's a bug. Talk to the
implementation vendor.




>
> 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.
> > >
>