Hi,

The whole point is that, when u is very close to 1,
-std::log(result_type(1) - u) * lambda_inv; would have returned
infinity because "result_type(1) - u" ends up being 0.

by representing that difference by -u, that situation is avoided, so
there IS increased resolution. -u can be represented by subnormal
numbers, and std::log is able to give very good values for those
subnormal numbers.

on your second comment: "makes the distribution less accurate near 0,
as it skips over a lot of representable values", could you develop
further?

Thanks,
Lucas

On Sat, 6 Dec 2025 at 01:09, Lénárd Szolnoki <cpp_at_[hidden]> wrote:
>
>
>
> 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
>