WIP: use L128X1024Mix for random generator

[vlsi]

Overview

See https://github.com/jlink/jqwik/issues/363

This is more like work-in-progress, however, it looks like the changes are not really big.

Basically:

• long seed -> JqwikRandomState seed
• Random -> JqwikRandom
• The seed looks like in base36. It takes 198 chars, it is easy to select by double-clicking. If we add upper-case letters, then it would be 172 chars, which is not a significant improvement, however, we won't be able to reuse Java's standard base36 encode-decode. seed = 1piidb7t9rfnx31xty9qfxo1jlx1qi9wkegpnxl5w4geilda60j7rbjntetpvuuveabbeejzi02hl4pmwmjaoe61mv8iny98hlgfmgq36fqiw9kdpeocp8qhvj84j56l7g1xhlxlfkr7sne536w2d0rvmksz1ze3gd0y3y3jwfa7q3m3myaj6qi3wwmxdi5mdig2jmy1a3jwb58g4i95aow5h6hodvkom8i9xeuafi4ug009s2maxqyele0gzcz4ykihtvprq7d059n29lpy3hb5qiz29| random seed to reproduce generated values

There's a possibility to use net.jqwik.api.Random, however, I am afraid it would clash with java.util.Random.

I'm not sure if it is worth making a distinction between the seed (the one you use to create a random generator), and the state of the generator.

Commons-rng allows to export the state of a random generator to an object, however, it does not provide cross-version compatibility for that state. In other words we can't use saveState/restoreState for @Property(seed="...")

At the same time, if we use .split(), .jump() for splitting the generator instead of nextSeed=random.nextLong(), then the only thing we can have is the internal, non-serializable state of the newly split generator. We can't really infer "the values we should pass as byte[]seed in order to produce the same generator, as we got after the split"

I would try adding both seed (optional) and state (optional, computed from seed if missing) to an opaque interface JqwikRandomState. Then we could both have cross-version seed values and use random.split() in the test engine.

WDYT?

---

I hereby agree to the terms of the jqwik Contributor Agreement.

[jlink]

I need more time for analysis to see if I want jqwik to go that route. As other PBT libs - eg hypothesis for Python - show, the underlying stream of random bytes/numbers can be a good foundation for shrinking as well. If jqwik adopted that idea, RNG-related code would have to be redesigned from scratch anyway - at least I think it should.