On Sun, 7 Dec 2025, 20:15 Marcin Jaczewski, <marcinjaczewski86_at_[hidden]>
wrote:

> niedz., 7 gru 2025 o 20:26 Jonathan Wakely <cxx_at_[hidden]> napisał(a):
> >
> >
> >
> > On Sun, 7 Dec 2025, 19:11 Marcin Jaczewski, <marcinjaczewski86_at_[hidden]>
> wrote:
> >>
> >> niedz., 7 gru 2025 o 19:05 Jonathan Wakely via Std-Proposals
> >> <std-proposals_at_[hidden]> napisał(a):
> >> >
> >> >
> >> >
> >> > On Sun, 7 Dec 2025, 15:04 Juan Lucas Rey, <juanlucasrey_at_[hidden]>
> wrote:
> >> >>
> >> >>
> >> >> Also something that is confusing to me from this process is that, if
> the standard specifies that the return values from generate_canonical are
> to be smaller than 1, then why is the standard concerned with
> implementation problems? why does LWG 2525 even exist? If the standard says
> it should return values in [0,1), and implementations don’t respect that,
> then that’s hardly a problem of the standard right?
> >> >>
> >> >> That seems to be an implementation problem, and is properly
> addressed at the implementation level by GCC #63176
> >> >
> >> >
> >> > The GCC solution is non-conforming. We are implementing p0952 as a
> better solution.
> >> >
> >> >> LLVM #18767
> >> >
> >> >
> >> > This isn't fixed yet, as far as I know.
> >> >
> >> >
> >> >> and MSVC STL #1074.
> >> >
> >> >
> >> > The MSVC solution was to implement p0952 which means it is not
> conforming to the old spec, because it sometimes discards random numbers.
> >> >
> >> > So it's not just an implementation problem if the spec is
> implementable, and so implementations can only be fixed by either breaking
> the rules of the standard or changing the standard.
> >> >
> >>
> >> If we need to break implementations by changing standard, could the
> >> standard at least require exact same results on every implementation?
> >
> >
> > No, not easily.
> >
> >
> >> Like in multiplayer video games whole simulation is run indepedly on
> >> every machine and each one need to use diffrent compiler (like android
> >> phone have Clang, Linux use GCC and Windows use MSVC).
> >> If each implementation have freedom to use any algorithm as long it
> >> preserve probability then game will desync players with code from
> >> other compilers.
> >>
> >> Of course this will have drawbacks as sometimes some enforced
> >> algorithms will not be perfect and can't be updated if they have bugs.
> >> Maybe we should have some group of algorithms that guarantee the same
> >> results on all implementations?
> >
> >
> > https://wg21.link/p3375
> >
> >
>
> Yes, but this is a bigger topic, I think more focused on related
> problem in random distributions,


How do you expect to have reproducible random distributions if you can't
even multiply or divide floating-point numbers with reproducible results,
let alone call log, exp etc?

The bigger topic is a prerequisite for the "simple" topic of random floats.


I recall cases where some silly
> change makes
> two implementations "incompatible".


Which cases?


Both follow standard to letter.


The standard doesn't require any particular algorithm for most of <random>,
so there's no letter to follow. There is no requirement to be close to
anything or to produce any particular sequence of numbers. Only the random
engines (e.g. the mersenne twister implementation) have to produce
particular numbers required by the standard.

It would be difficult/pointless to specify a particular algorithm in code
when for example the size of long double varies by compiler, processor, and
OS.


So
> close but at the same time so far.
>