[Development] Notes on QtCore session @ QCS2016

[Matthew Woehlke]

On 2016-09-05 20:02, Thiago Macieira wrote:
> Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo 
> escreveu:
>> Il 02/09/2016 17:01, Thiago Macieira ha scritto:
>>> https://wiki.qt.io/QtCS2016_QtCore
>>>
>>> * Deprecation of APIs
>>>
>>>     * qrand/qsrand -> replacement is Standard Library or your own
>>
>> Unfortunately there's no replacement for a thread safe, easy to use,
>> deterministic, low quality random number generator. std::rand is not
>> thread safe and the whole random API is not exactly user friendly...

  class RandomSource
  {
    ...
    double operator()()
    {
      m_seed = ((19073486328125 * m_seed) + 1) & 0x7fffffffffffffff;
      return ldexp(static_cast<double>(m_seed), -63);
    }
  }

  auto r = RandomSource{}; // or construct with a known initial seed
  auto first_random_value = r();
  auto next_random_value = r();

Class boilerplate omitted. A thread-local instance of this would give
you thread safety, or depending on how you need to use it, you can just
instantiate your own instance. Producing a "good" initial seed is more
complicated, but for determinism obviously you will supply a known
initial seed.

FTR, I wrote this *after* C++11 <random> came out. It's faster¹ than
C++11 <random>, has "pretty good" randomness characteristics, and is
much, much easier to use. Having this or similar in Qt (with a suitable
means of initial seeding) could indeed be still useful.

(¹ IIRC... at least compared to the libstdc++ implementation at the
time, although it's hard to imagine how it could possibly be *slower*
given how trivial the code is.)

> You're right the std:: API is not user-friendly. In fact, it's plainly user-
> hostile, requiring multiple template arguments, creating objects that should 
> only be used with auto, and has a major problem with properly seeding the 
> entropy in certain scenarios. Still, the conclusion of the discussion is that 
> we don't to write a wrapper API. We should get the high-quality generator and 
> that should suffice for everyone.

I will never, *ever* replace the PRNG shown with a high quality
generator. The use case for which I wrote this - computer VFX, basically
(think 'video games') - specifically needs a LOT of random numbers.
Speed is critical, and the algorithm shown is essentially the fastest
possible algorithm short of a LUT. A high quality (read: slow) algorithm
would be completely unacceptable for my use case (though possibly useful
for initial seeding).

I'm not sure I'd use a high quality (slow) generator even for something
like game AI. Using it for procedural content generation is out of the
question.

-- 
Matthew