Way to read seed in order to replay next time with it

[a-voronov]

Hi!
I'm about to use RandomKit for unit-testing.
Is there any way to save current seed and be able to create generator with the same seed next time in order to reproduce tests with same generated values?

Something like this, but not to do whole thing every time.

let x = UInt64.random(using: &Xoroshiro.default) // 10836192520054005588
let y = UInt64.random(using: &Xoroshiro.default) // 11819366441135859839

var r = Xoroshiro(seed: (x, y))
let z = UInt64.random(using: &r)                 // 4208814887480313811

So basically, for Xoroshiro, it would be exposing _state variable for read-only purposes.

[nvzqz]

Xoroshiro is a struct so it gets copied around when passed by value. You can just save a copy of r somewhere. This would essentially be the same as saving r._state somewhere, except you wouldn't need to construct the generator each time with init(seed:).

I'm not sure if this answers your question.

[a-voronov]

Sure, but I mean saving some human-readable seed that I can use later in case I'm interested in replaying test suite with it.

So as a concrete example - I start my tests and see something like Seeded with (10836192520054005588, 11819366441135859839) in my logs.
So in case my tests fail with some interesting value, that was randomly generated, I can manually create Xoroshiro generator and copy-paste values from that seed to replay tests and see if issue was fixed.

[nvzqz]

You could access the internal values via reflection. Also, I believe print-ing the generator should show the internal seed since they type doesn't implement a custom mirror. I don't see any harm in making _state public so I may do that at some point in the future.

[a-voronov]

Thanks for the answer!
Indeed I can use Mirror to get _state value, so it might work for now.

I don't see any harm in making _state public so I may do that at some point in the future.

This was actually my main concern, but I'm glad it's fine.

Anyway, I've created small pull request #44
Not sure if it's totally correct from algorithms perspective though.
It doesn't include SeedableFromSequence yet, but I can proceed with it once changes to Seedable are correct.