Hi,

If you look at https://cplusplus.github.io/LWG/issue2524, it says clearly there:

"Original title was: exponential_distribution<float> sometimes returns inf.
The random number distribution class template
exponential_distribution<float> may return "inf" "

and that's what I am trying to address with my proposal. Now you tell
me there is no problem there, the problem is in
std::generate_canonical.
fine. Nothing confusing there.

Lucas

On Fri, 5 Dec 2025 at 14:35, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
>
> 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.