Random numbers

[deleted account xyzzy]

If'n you want a few lines of easy to use code for generating random numbers you could look at this random toolkit from a C++ working group proposal:

https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3551.pdf

I tweaked it a bit and created header-only/module interface files that you add one or the other to your project and get easy-to-use functionality like C's <cstdlib> srand/rand functions.

https://github.com/GeorgePimpleton/misc_files/tree/main/Random%20Toolkit

[Peter87]

Note that for std::uniform_real_distribution the upper bound is not included in the range so you might want to change

if (from > to) { throw std::invalid_argument("bad double distribution params"); }

to

if (from >= to) { throw std::invalid_argument("bad double distribution params"); }

[deleted account xyzzy]

I freely admit that RTK is a work-in-progress, so the suggested change is most graciously accepted. Provisionally :)

I've been staring at that code for so long, so how I missed such a potential minor change is just an big "ooops!"

Weird how cppreference write-up on std::uniform_real_distribution's params seems to indicate the upper bound is included in the range.
https://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution/params

[Peter87]

It seems like constructing the range with those parameters is alright but actually using it to generate a random number is not?

Cppreference.com has a note that says the following about the constructor:

If a == b, subsequent calls to the operator() overload that does not accept a param_type object will cause undefined behavior.

https://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution/uniform_real_distribution

But it says nothing about this for the operator() overload that accept a param_type (which is what you're using).
https://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution/operator()

I guess it just follows from the probability density function P(x|a,b)=1/(b−a). If a == b that leads to division by zero which is undefined.

The standard itself actually contains a note about this:

[Note 1: This implies that p(x | a,b) is undefined when a == b. — end note]

https://eel.is/c++draft/rand.dist.uni.real#note-1

[deleted account xyzzy]

The only check for the params I am trying to make is the lower bound is not greater than upper bound.

The code is not bullet-proof, designed to catch every flavor and nuance of potential misuse. As long as 'a' is less than 'b' I'm happy.

But as I said earlier, your suggestion of >= for std::uniform_real_distribution is well founded and will be implemented. :)

[deleted account xyzzy]

Now that I really take a look at the ctor notes at cppreference for std::uniform_real_distribution there is an additional check I probably should make for bad params:

      if ( from >= to || ((from - to) > std::numeric_limits<double>::max()) )
      {
         throw std::invalid_argument("bad double distribution params");
      }

Bad params are either in reversed order or equal, OR the params exceed the maximum finite value a double can hold. Do I read the ctor notes correctly and have the two test conditions correct?

I've been staring at this code for so long I need a fresh pair of eyes.

[Peter87]

Yes, it looks like you're testing correctly.

Wait a minute! It should be (to - from) otherwise you'll get a negative number.

[deleted account xyzzy]

Heh, as I said I needed a fresh pairs of eyes on this, and dammit I was correct. (from - to) looked correct.

cppreference has it as b-a. :|

Gi'e me a few minutes to correct my "correction" and update the github repo. I wanna be able to call this omelet done.

[deleted account xyzzy]

Admittedly this RTK isn't cryptographically robust, but that isn't the stated intent. I want to have something that makes using the <random> library as easy as using the C library functions. Either as a stand-alone header or module interface file.

[Peter87]

George P wrote:

cppreference has it as b-a. :|

b = to
a = from

[deleted account xyzzy]

I realize what a and b represent, really. :) I simply made a hooman mistake of long hours staring at code and lots of bad coffee.

[seeplus]

lots of bad coffee

Ahhhh - always get your priorities right and go for good coffee!

[deleted account xyzzy]

Good coffee is just wasted on this Pleb and villein.