“

The proposal seems quite confused (or at least unclear) about what problem is trying to solve. ”

I think it was clear from my last email that the problem I’m trying to solve is that generate _canonical returns an interval that is problematic: it has good resolution on one tail and bad resolution on the other. This is the source of the problem of generate _canonical returning 1. (And as a consequence it generates the problem of certain implementations having generate _exponential returning infinity, but as stated before this is an implementation problem, not a standard one).

On Sun, 7 Dec 2025 at 10:22, Jonathan Wakely <cxx_at_[hidden]> wrote:

On Sun, 7 Dec 2025, 08:49 Lénárd Szolnoki, <cpp_at_[hidden]> wrote:

On 05/12/2025 18:25, Jonathan Wakely via Std-Proposals wrote:
>
>
> On Fri, 5 Dec 2025 at 14:34, Jonathan Wakely <cxx_at_[hidden] <mailto:cxx_at_[hidden]>> wrote:
>
>
>
>     On Fri, 5 Dec 2025 at 14:06, Juan Lucas Rey <juanlucasrey_at_[hidden]
>     <mailto: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.
>
>
> Finally, I don't see how making more use of the increased precision near zero actually
> helps. The purpose of std::generate_canonical is to produce values uniformly distributed
> in the range [0,1). Producing more values close to zero because there is a higher density
> of representable values there does not meet the contract.

The way it helps is that the way the centered distribution is sliced and rearranged, it
produces a uniform distribution on (0, 1], and then the produced value is used directly as
-log(u).

The way libstdc++ (and I assume other implementations as well) do it, is that it produces
a uniform distribution on [0, 1), and then use it as -log(1-u). 1-u has reduced precision
close to 0 (in fact on the whole range of (0, 0.5)). Using 1-u is effectively equivalent
to generating a fixed-point number between 0 and 1 with 24 bits of mantissa in terms of
precision (assuming float).

If we deem the resulting exponential distribution acceptable then this algorithm is quite
wasteful in how it uses the random generator, as it only uses a fixed 24 bits of entropy,
but consumes a lot more bits from the generator to generate the intermediate
generate_canonical.

Which could be solved by changing the implementation of exponential_distribution, right? Nothing says it has to make exactly one call to generate_canonical<result_type>. For example, it could use at least double (instead of float) for the call to generate_canonical. Or use something completely different from generate_canonical, like the centred function in the proposal.

The proposal seems quite confused (or at least unclear) about what problem is trying to solve. Is it about exponential distribution (and *only* exponential distribution?) being low quality when used with float? Or is it about the reproducibility of values from the C++23 spec for generate canonical? 

If the proposal is to make progress, I'd like to see a clear problem statement, and a more detailed description of what is actually being proposed and how it solves the problem.

e.g. "Using generate_canonical<float> for exponential_distribution<float> is bad because ..." and/or "the P0952R2 changes to std::generate_canonical are a problem because ..." and/or something else. Not just vague references to backwards compatibility and brief mentions of subnormals which are irrelevant to the P0952R2 changes.

A proposal should do more than show a single function declaration with no description of its semantics and no discussion of what other changes implementations might need to make.