No announcement yet.

On Hamming Weight

  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    It's not useless for unsigned integers.
    The floating point number represented this way can hold all 64 bit integers, signed or unsigned.
    If you stop using the 64 bits as an integer and just want to manipulate bits then that might be an problem for the FPU but for numerical calculations, the FPU has no problem holding and calculating with the full 64 bits, signed or unsigned.


    • #42
      Originally posted by "Dale
      Sorry for interruption David.
      That's OK I am done here now.


      • #43
        Originally posted by Yours truly
        That's OK I am done here now.
        Famous last words.

        All the conclusions above are based upon examining PCG32.

        Here is a snapshot from one of Sebastiano Vigna's papers: page 19

        It is clear that xorshift64* does not need a warm-up. WELL19937a looks like it needs about 130 samples to be burnt to get to an optimal state vector. The Mersenne Twister is horrendous.

        Now if we forced an initial state vector to be optimal, then we would not need a warm-up on any of the PRNGs tested. However, if any of the PRNGs requiring a warm-up drifted into a tail during a generator session we could be in the tail for quite a while with some and, there is nothing we can do about it. Needless to say, this does not bode well for the Mersenne Twister; probably one of the most popular PRNGs this century and no longer recommended by many. In fact, it fails PractRand (v0.94) test at 256GB. That is many bytes, but it is only 64 Gigs of DWORDS.

        Looking at PCG32 it seems, like xorshift64*, it does not need a warm-up. It follows then that if we drift into a tail we should be out quickly and this has been found, from above, to be true. Bernard Widynski's Middle Square Weyl Sequence RNG (MsWs) [ May 20, 2020 ] does not need a warm-up either, and it also will be of no concern if it drifted into a tail. I chose PCG32 over MsWs when deciding what to use for a dll because PCG32 is faster.

        The conclusion then is if a generator needs a warm-up then, although we can mitigate that by forcing the initial state vector to be optimal, that does not help us when the generator passes through a partial sequence of low entropy state vectors during a generator session. That is easily remedied - don't use them. This is contrary to the consensus that we should be OK by warming up generators as a matter of course; and what I have been saying for a few years.

        PCG32 hit the streets in 2014 and has been one of my favourites ever since. It would appear that it is better than I thought it was. It is clear that getting the occasional 'Evaluation unusual' during a PractRand run has nothing to do with the Hamming Weight of the state vector. That cannot be said of those PRNGs which required a lengthy warm-up.

        Of course, examining the HW of the state vector should be credited to Vigna, but he fell short by not considering the HW of the state vector beyond the early stages of a generator session.

        Life gets a little more complicated with state vectors of two or four QWORDS, as with Vigna's xoroshiro128** and xoshiro256**, and why I chose PCG32 which uses just one QWORD. Those Vigna generators output 64 bits and come into their own with 64-bit applications.


        • #44
          I forgot to post the snapshot.

          Click image for larger version

Name:	ZeroLand.jpg
Views:	7
Size:	63.7 KB
ID:	810967