Date: Sat, 6 Dec 2025 01:08:56 +0000
On 05/12/2025 22:32, Lénárd Szolnoki via Std-Proposals wrote:
>
>
> On 04/12/2025 19:05, Juan Lucas Rey via Std-Proposals wrote:
>> in the current proposal,
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0952r2.html
>>
>> it is mentioned "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."
>>
>> This solution avoids breaking this.
>
> In the attached proposal within the implementation of exponential_distribution you have:
>
> const auto u
> = std::generate_canonical_centered<
> result_type,
> std::numeric_limits<result_type>::digits
> >(g);
> if (std::copysign(1.0, u) > 0) {
> return -std::log(result_type(1) - u) * lambda_inv;
> } else {
> return -std::log(-u) * lambda_inv;
> }
>
> This is exactly equivalent to:
>
> const auto u = ...
> const auto u2
> = std::copysign(1.0, u) > 0
> ? result_type(1) - u
> : -u;
> return -std::log(u2) * lambda_inv;
>
> Generating the centered uniform distribution seems redundant, you effectively map it to a
> uniform distribution on [0, 1) anyway with u2. So this also boils down to fixing the
> distribution on [0, 1), and centering doesn't give you anything for this particular use
> case. You throw away your increased resolution at `result_type(1) - u`.
Correction, for u2 you effectively generate uniformly on (0, 1]. This improves the tail
distribution of the generated exponential_distribution compared to using
generate_canonical, but makes the distribution less accurate near 0, as it skips over a
lot of representable values.
Honestly, neither technique is great in terms of accuracy, and it's probably possible to
implement exponential_distribution in a way that it can actually take any representable
value within the distribution. And the exponential distribution has density beyond
FLT_MAX, so theoretically inf is a valid result, but the probability of rolling above
FLT_MAX is usually beyond astronomically low, so I guess fixing that made sense.
>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> On 04/12/2025 19:05, Juan Lucas Rey via Std-Proposals wrote:
>> in the current proposal,
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0952r2.html
>>
>> it is mentioned "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."
>>
>> This solution avoids breaking this.
>
> In the attached proposal within the implementation of exponential_distribution you have:
>
> const auto u
> = std::generate_canonical_centered<
> result_type,
> std::numeric_limits<result_type>::digits
> >(g);
> if (std::copysign(1.0, u) > 0) {
> return -std::log(result_type(1) - u) * lambda_inv;
> } else {
> return -std::log(-u) * lambda_inv;
> }
>
> This is exactly equivalent to:
>
> const auto u = ...
> const auto u2
> = std::copysign(1.0, u) > 0
> ? result_type(1) - u
> : -u;
> return -std::log(u2) * lambda_inv;
>
> Generating the centered uniform distribution seems redundant, you effectively map it to a
> uniform distribution on [0, 1) anyway with u2. So this also boils down to fixing the
> distribution on [0, 1), and centering doesn't give you anything for this particular use
> case. You throw away your increased resolution at `result_type(1) - u`.
Correction, for u2 you effectively generate uniformly on (0, 1]. This improves the tail
distribution of the generated exponential_distribution compared to using
generate_canonical, but makes the distribution less accurate near 0, as it skips over a
lot of representable values.
Honestly, neither technique is great in terms of accuracy, and it's probably possible to
implement exponential_distribution in a way that it can actually take any representable
value within the distribution. And the exponential distribution has density beyond
FLT_MAX, so theoretically inf is a valid result, but the probability of rolling above
FLT_MAX is usually beyond astronomically low, so I guess fixing that made sense.
>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-12-06 01:09:04
