cauldron VS mersenne-twister-predictor

I've previously written an algorithm that generates random floats in any [a,b], which can generate all possible floating point values, including subnormals, with the proper probability, and does so quickly for any choice of a and b. [0]

[0] https://github.com/camel-cdr/cauldron/blob/main/cauldron/ran...

The major advantage here is that you don't need to parse a dsl, and you can still have formatting options. A final api would probably use automatic compound literal struct arguments to implement default arguments with names parameters.

Type detection should also be possible, although you would need to register all print functions in a global macro.

This is just a proof of concept: https://github.com/camel-cdr/cauldron/blob/main/ideas/fmt.c

This is just a proof of concept: https://github.com/camel-cdr/cauldron/blob/main/ideas/fmt.c

It really depends on your use case, but I've written a header only PRNG library that might be interesting to you. I've also held a presentation about it, if you are interested in the specifics: "How computers generate random numbers (A guide for programmers)"

I've put it through an adapted version of testgauss.c, and it passed the test.

The entire romu-random.org family is faster than xoshiro256++, atleast in my benchmark:

Now for the self promo: If you are interested in random number generation, check out my presentation on the topic: https://www.youtube.com/watch?v=VHJUlRiRDCY You can also check out my random number library: https://github.com/camel-cdr/cauldron/blob/main/cauldron/random.h

For my benchmarking library, I use macros to tell the compiler not to optimize away a value, pre-running the benchmark to "warm up" the CPU/scheduler and calculate the average and deviation of multiple runs of the benchmark.

So, extracting information out of a completely unknown random generator is already pretty tricky. If you know you are dealing with a mersenne twister it is doable for sure, but even if you are dealing with the pretty basic MT19937 (which has a period of 219937-1) which is for instance included in the c standard library you need a few hundred numbers (https://github.com/kmyk/mersenne-twister-predictor) to guess the next one. This assumes that you have those exact numbers. Network latency (unless GGG would track the data directly on the client, fair enough) would muddy it further so that you would need a larger amount of data to verify it. How much more I have no fucking clue.