tbxfreeware

You are right! A workaround solution is to add 4 instead of adding 1 when you increase the seed value. Here are notes I made when I discovered this problem...

O'Neill's implementations of `operator>>` and `operator 1);` When the new_increment is 0, however, `new_increment >> 1` is also 0, so this call is the same as `rng.set_stream(0);`. The final step...

Here is a short program that verifies the bug described above. It is a complete program, so you should be able to copy, paste, and compile without any need to...

A similar question from May 2019 remains open: [ Is this being proposed for standardization? #51 ](https://github.com/imneme/pcg-cpp/issues/51).

> One issue that came up is a difference in the construction of MCGs (e.g. `pcg64_fast`): > > * `pcg-c` uses `initstate | 1u` to seed an MCG [src](https://github.com/imneme/pcg-c/blob/master/include/pcg_variants.h#L812) >...

You nailed it. `output_previous` is what causes this. Note, however, that the two generators in your example both use the same seed. Rather than using different seeds to generate different...

Here is a short program you can run to verify that this bug does, indeed, exist. ````c++ // main.cpp #include #include #include "pcg_random.hpp" using state_type = pcg32::state_type; state_type arbitrary_stream() {...

> It seems seeding with std::seed_seq doesn't have this issue, ... Calling `seed` with a _seed sequence_ does not reset the "default" stream. It does, however, discard the existing stream,...

At present, the obvious work-around/fix for this bug is to use brute force. If possible, set the stream and seed at the same time. Otherwise, save and restore the stream...

The behavior you observe is normal. It is caused by the "conditioning" process used to randomize the seeds you give to PCG. Seeds are used to set the state of...