On Wed, Nov 24, 2021 at 11:05 AM Dimitrij Mijoski via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Tue, 2021-11-23 at 23:28 -0500, Jason McKesson via Std-Proposals
> wrote:
> > The SSeq constructor for MT is explicitly defined to generate a
> > specific number of integers, sufficient to fill up the state. It
> > generates no less and no more than that, no matter what their values
> > are. The generated values are copied directly into the internal state.
> >
> > The MT constructor is defined to do some fiddling with the state in
> > certain isolated circumstances, but it never *generates* more data.
> > Nor is the SSeq required to provide any particular mechanism for
> > generating bits. So whatever "this protection" is, it has nothing to
> > do with the *mechanism* used to generate those bits.
> >
> > So yes, *any RNG engine* can be used to do the stretching, if it
> > provides the SSeq interface. The SSeq interface is not *required* to
> > be implemented by `seed_seq`.
>
> I am well aware of this. But I'm under the impression that some people
> want to completely sidestep the MT13997 constructor and write directly
> into the state. That is 20 year old mistake, fixed in 2002, but I have
> the feeling that fix got forgotten. Just look at this reddit comment,
> it's terrible
> https://www.reddit.com/r/cpp/comments/r0idct/underseeding_mt19937_introducing_xoshiro256ss/hlttb2t/?utm_source=reddit&utm_medium=web2x&context=3

What does that have to do with anything that's been said *here*? If
you want to argue with someone on Reddit, feel free, but there's no
point in projecting other people's ideas onto us here unless we've
said the same thing.

Which nobody here has.

Nothing about any of the proposals has a problem with the mechanism MT
uses to extract and manipulate the bits it is given as a seed. It's
all about how those bits get *provided* to the constructor.