cauldron VS libcperciva

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.

On the topic of compilers being hard: In my repositories I'm carrying around a 5 year old workaround (https://github.com/Tarsnap/libcperciva/commit/92e666e59503de...) for a 6 year old bug (https://bugs.llvm.org/show_bug.cgi?id=21183) in clang/LLVM.

You might think that "incorrect code gets generated" would be a maximum-priority must-fix-before-the-next-release bug in a compiler, but apparently not.