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


Your proposal needs to say that then. Because currently it says:

*0.4 3. Proposal*
Add the following to <random>:
namespace std {
template<class RealType = double, int bits, class URNG>
RealType generate_canonical_centered(URNG& g);
}

Is that it? That's the whole proposal?!
Apparently not, apparently you want to change std::exponential_distribution
too. What about the other 20+ places that use std::generate_canonical?

So in summary:

You should explain that where P0952R2 says "In particular, code that
depends on a specific sequence of results from repeated invocations, *or on
a particular number of calls to the URBG argument*, will be broken" that
it's the second part (in bold) that is a problem for your. Based on your
initial PDF proposal there is no clue whether the compatibility you're
talking about is the exact sequence of values returned, or the number of
invocations of the URBG. The word "discard" doesn't even appear in the
proposal.

Your abstract says "without altering existing behavior". I think you mean
"without altering the C++23 behaviour", but you should be clear about what
you mean by "existing". P0952R2 is already part of the C++26 draft.
Assuming you mean "without changing the C++23 behaviour", how does
proposing a completely different function help? The P0952R2 changes would
still be in C++26, and so that's still a change from C++23. How does a
different function with different behaviour undo the changes to
std::generate_canonical?!

You need to be clear about what you're actually proposing, and the impact
on implementations (they would need to replace some or all internal uses of
std::generate_canonical with your new function, and adjust to deal with a
completely different output range?)


Currently the proposal is vague and contradictory and confusing.