Random VS proptest

Sure here is a an example (repository) (click "run" to see it work) contrasting the two in Rust, note that it is not fully symbolic, just the imaginary component. But the immediate advantage one can see is allowing direct computation without needing to modify the polynomial multiplication algorithm. (As noted in the source code, this is a purely theoretical advantage).

I can't help you with the specific website, but here's a trivial cli implementation of Game of Life.

I've been sitting on my hands when it comes to updating my library, but if you really want a fast test, you can use some of my research/implementation for RCPrime, with creditation of course. I'm not sure what algorithms FLINT uses, but I'm fairly certain that the RCPrime implementation is the most efficient for integers less than 2^35 (requiring 64 multiplications and only one strong fermat test) even if you implement with Montgomery exponentiation.

Here is a sample implementation along with the inverses of the first 128 primes (in hex). (Except 2, which can be easily checked by the &1 trick)

Not what one normally considers in CS, but producing a fast deterministic test for checking primality in the interval 0;2^64 with some extensions beyond. Fully constructing one to 2^128 is well beyond what is currently computable, however some progress has been made that surpasses published bounds.

Working on developing a faster and smaller primality check in the interval 0;2^64 with tentative extensions towards 2^65. While it performs satisfactorily for the intervals currently available, reducing the memory to less than other implementations is a major challenge.

See this other approach for a similar engine, that utilizes a linear bitvector to model cellular automata.

You are way overthinking it. For something like minesweeper you can just model an integer lattice, and use either a 1d vector of integers to represent the positions of the mines or a 1d bitvector and check the values in the chebyshev distance of 1 from the point. (If you use integers like in the first example, your system becomes a plane of 2^32, 2^32 dimensions and is bounded by the number of mines (64-bit integers) that can fit in your RAM)

You can look here for some slightly better ways to test for primality (ignore the different language).

RAND calls a hardware source of Johnson-Nyquist noise (basically electric static), and then performs some filtering on it to make sure that it's evenly distributed. There are faster methods, like a simple "linear" rng, but they frequently don't give as good results.

proptest: Property-based testing with random input generation.

Isn't proptest something that could handle this?

https://github.com/proptest-rs/proptest

Proptest is a Rust crate for property-based testing. Recently I wanted/needed to manually implement a proptest strategy for my own type, and I realized that there is not that much material on how to do it. So I wrote a post where I tried to describe what I learned. It's a bit niche, but I hope that someone at some point will find it useful.

Take a look at proptest.

Yes exactly, you can also add to this fuzzing and property based testing.

proptest is great! It generates random input data according to some rules, and if the input fails it saves random seed into a file so that failing inputs are guaranteed to be tested on the subsequent runs (as well as new random inputs). It also doesn't immediately stop on fail but tries to find a minimal failing input first.

The only other crate I could find is proptest, but it looks a lot more complicated, and I don't know if lets you skip the shrinking step as quickcheck does. I've been reading the book and going through the docs, but a quick answer would be appreciated.

We just released proptest 1.1.0, a property-testing framework for Rust. Proptest has recently found new maintainers, and this marks the first new release of proptest in ~2 years.

Hi, I'm working on a fuzzer, that fuzzes APIs based on OpenAPI specification. I'd like to implement shrinking. It means that when an interesting input (for the API) is found, I'd like to create the smallest possible input that still causes the same behaviour of the API. I'd like to implement a payload generation via proptest, because it already has the shrinking ability. I'm having issues implementing the JSON object as a proptest strategy. Here is what I tried so far. I explained it in a detail in stackoverflow question but it did not reach many people. Thanks for your help!

Third, if you're opting out of a compile-time safety guarantee in the name of performance, test heavily (high-coverage unit tests, property testing, fuzzing, differential fuzzing, etc.) and make use of tools like Loom and Miri's runtime data race detector for unsafe code, which can catch stuff that is beyond the scope of the compiler's guarantees.