Add tests based on the reference implementation in C. about scala-xoroshiro128 HOT 13 CLOSED

@mscharley these look like 32 bit outputs.

I've been getting 64 bit output at https://github.com/thedavidmeister/xoroshiro128/blob/master/test/xoroshiro128/core_test.clj

from scala-xoroshiro128.

Yes, 128 bit state (hence the name) and 64 bit output is definitely what's intented. Now that you point it out, it does looks like you're correct, these numbers are far too short. Probably a mistake in the printf() call, i'll look into it.

from scala-xoroshiro128.

Oh boy, only in C... (emphasis mine)

... as far as I remember the MS C Compiler (when set up to compile straight C [ie. not C++]) is supposed to be C90 compliant by design; C99 introduced some things that not everyone liked

from scala-xoroshiro128.

@thedavidmeister I've updated this issue with actual 64b numbers. I was write, the format string in printf() was only specifying a 32b integer output. Oops.

from scala-xoroshiro128.

@mscharley i had a play with the ide, very helpful

I forked it and added lots more verbose debug output here - https://ideone.com/PuauK5

You can see that it appears that line 27 sm_s = seeds[i]; doesn't do what i think you think it does.

If it did, all 4 of these numbers would be the same :/

from scala-xoroshiro128.

Oops, seeds are still defined incorrectly. Will fix tonight

On Wed, 10 Aug 2016, 00:53 David Meister [email protected] wrote:

@mscharley https://github.com/mscharley i had a play with the ide, very
helpful

I forked it and added lots more verbose debug output here -
https://ideone.com/PuauK5

You can see that it appears that line 27 sm_s = seeds[i]; doesn't do what
i think you think it does.

If it did, all 4 of these numbers would be the same :/

[image: screen shot 2016-08-10 at 12 53 09 am]
https://cloud.githubusercontent.com/assets/629710/17520959/dbeefd7a-5e94-11e6-910c-e2027b8c713d.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUifXPfF_ZU202VLVeAh01lrhUhTy70ks5qeJSDgaJpZM4JfKX5
.

from scala-xoroshiro128.

uint64_t* seeds[5];

should be:

uint64_t seeds[5];

ie. An array, not a pointer to an array.

from scala-xoroshiro128.

@mscharley https://ideone.com/PuauK5 is working for me now.

This was really great, I picked up a couple of bugs in my implementation of the jump function. I think the clojure version is pretty rock solid now.

from scala-xoroshiro128.

Awesome! Glad to hear it. Yeah, the next function is pretty standard math but the jump function is especially magical.

from scala-xoroshiro128.

@thedavidmeister Another good test to have for your clojure version is that the following condition is satisfied (from their spec):

[jump()] is equivalent to 2^64 calls to next().

from scala-xoroshiro128.

Yup, every single line is magic. I have no idea what any of this does, lol.

  (jump
    [this]
    ; 0xbeac0467eba5facb = -4707382666127344949
    ; 0xd86b048b86aa9922 = -2852180941702784734
    (let [s   (atom '(0 0))
          x   (atom this)]
      (doseq [^long i [-4707382666127344949 -2852180941702784734]
              ^long b (range 64)]
        (when-not (= 0 (bit-and i (bit-shift-left 1 b)))
                  (swap! s #(map bit-xor % (seed @x))))
        (swap! x next))
      (apply xoroshiro128+ @s))))

from scala-xoroshiro128.

incidentally, at 27ns per call, it would take nearly 160,000 years to calculate 2^64 calls to next through brute force, so I'm happy to trust the math for this one ;)

user=> (-> (Math/pow 2 64) (* 27) (* 10E-9) (/ 60) (/ 60) (/ 24) (/ 365))
157934.45268586944

from scala-xoroshiro128.

Sometimes I think we can't actually appreciate how big 64b numbers really are. People were wondering how long the UNIX epoch would last after shifting from 32b integers (covering 1900~2038) to 64b integers. The answer is: far beyond the heat death of the universe.

from scala-xoroshiro128.