On 07/12/2025 10:22, Jonathan Wakely wrote:
>
>
> On Sun, 7 Dec 2025, 08:49 Lénárd Szolnoki, <cpp_at_[hidden]
> <mailto: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]> <mailto: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]>
> > <mailto: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?

I do agree that the proposal is confused, or at least very incomplete. The precision and
inf problems of exponential_distribution, and possibly other distributions that are
unbounded, is purely QoI.

This QoI problem does have merit, IMO, and should be pursued by contributing to individual
implementations.

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